RFC2: Date/Time proposal

Charles Day cedayiv at gmail.com
Sat Jul 19 01:25:45 EDT 2008


I'm going to go ahead and throw out another proposal for comments. I'm
calling this RFC2. Unless specifically stated, all that follows refers to
transaction posting dates and times only.

Since to my knowledge the feature of having a "time zone per account" has
not actually been requested by any user, I'm going to leave that completely
out of this proposal. However, if there ever was a need for that feature in
the future, this proposal is readily extensible to support that.

Here's what I was thinking. The general idea is to allow "date only"
functionality, but also allow optional entry of a time of day:
1. Let there be a checkbox preference named "Show transaction posting
times". Off by default.
2. When this preference is off, registers look the same as today; a time of
day is not seen and cannot be entered.
3. When this preference is on, users can enter a posting time of day on any
transaction, but do not have to.
4. For each transaction, if a time of day has not been entered then the
GnuCash data file will only save the date. Otherwise, both date and the time
of day will be saved.
5. The user does not specify any time zone, and none is saved.
6. In case the user has some transactions with times and some without, and
needs to sort transactions by posting time, let there be a preference exists
to determine how to treat the transactions that do not have posting times.
(Possible options might include treating them as if they had been entered at
the beginning of the day, or at the end of the day, or at any specific time
in between.)

Sound good? Well, here's the part you may not like. All of the above can be
implemented by GnuCash internally by use of a timestamp and a flag
indicating whether the time of day was entered by the user. Let me explain:
A. All timestamps would use the same time zone, which never varies. Users do
not pick the time zone. It is hard coded and is never seen in the GUI and
never saved to the data file.
B. If a transaction is read from a data file and it contains both a date and
a time, these are combined with the time zone from (A) to compute a
timestamp. The flag is raised to indicate that the time of day was entered
by the user.
C. If a transaction is read from a data file and it contains only a date, a
time of day is added on according to the preference indicated in (6) above,
and these are combined with the time zone from (A) to compute a timestamp.
The flag is lowered to indicate that the time of day was NOT entered by the
user.
D. To display the date in the GUI, GnuCash takes the time zone from (A) and
the timestamp, and uses them to compute the date.
E. To (optionally) display the time in the GUI, GnuCash takes the time zone
from (A) and the timestamp, and uses them to compute the time of day.
F. When saving a transaction to the data file, if the flag is raised to
indicate that the time of day was entered by the user, then GnuCash writes
the date and time of day to the data file.
G. When saving a transaction to the data file, if the flag is lowered to
indicate that the time of day was NOT entered by the user, then GnuCash
writes only the date to the data file.

My reasons for suggesting the continued use of timestamps internally are
that it makes it very easy to sort transactions by posting time, and that
the necessary code changes to get this done is still fairly small. So there
is probably some reasonable chance of it actually getting done, which is an
important factor to consider. Several of you who want to use "date only"
internally have made fair points about simplicity, but I have made the point
that the effort of getting from here to there would be much larger. So you
would have to ponder the question of who would devote the necessary time for
that larger effort.

OK, now praise this, ask questions, or rip it apart (more likely) as you see
fit. Thanks to everyone so far for remaining fairly civil while discussing
this potentially incendiary topic.

Cheers,
Charles


More information about the gnucash-devel mailing list