RFC2: Date/Time proposal

Derek Atkins warlord at MIT.EDU
Tue Jul 22 04:26:23 EDT 2008

"Charles Day" <cedayiv at gmail.com> writes:

>     First, we're assuming that we ARE going to implement that feature,
>     which we don't necessarily need to.
> If we're not going to ever allow user-entered times on transactions, then we
> don't need this proposal. Just make the time zone a constant. This could be
> the immediate step to take; introduction of a time entry feature could come
> later.

I think the timezone should be a constant either way, and the
"default time" in the timestamp should also be a constant.
Then we can choose down the road whether to implement time-of-day
entry ala bug #89439

>     Second, I think it's perfectly fine to choose a default time regarless.
> Does the user get a choice of default time? If not, we don't need the
> preference from (6).

I would say "no".  I dont think it's needed.

>     Third, if we're just using the "time" to allow sorting of transactions
>     within a day, I don't think we need to store a timezone either.  We
>     just use GMT and let the user choose a time other than the default
>     (which I still think should just be 1200).
> We wouldn't need to store the time zone, but it would do no harm (keeps the
> file format the same).


> 0000 or 2359 seem like better options to me for a default time, i.e. treat
> transactions without user-entered times as being "beginning of day" or "end of
> day". Of course, if we have preference (6) then the user can make that call.

I still think 1200 is "better" because if we DO ever implement ToD entry
it makes it easier to move transactions forward/backwards from the default
without having to change the ToD on EVERY transaction that day.

>     As for the users who "dont want a time in their datafile", I'm perfectly
>     happy to ignore that "request".  They are absolutely correct that the
>     UI (register, reports, etc) MUST NOT behave differently when the user
>     changes a timezone, but I see no reason to support a requirement that
>     the data file NOT contain a time.
> Storing the time in the data file forces preference (6) into being a permanent
> choice, unless we also store a flag.

I'm afraid I don't follow your logic here.  Could you explain why
you say this?  We already store a time now and we don't have a
preference (6).  Had GnuCash kept a stable timezone always then
nobody would have every noticed there was a problem (except bug #89439)
and this discussion would be a VERY different animal.

>     Having said all that, we COULD put a flag in the KVP of the transaction
>     to flag that the time was entered by the user.
>  That would make preference (6) more flexible. I assume that's preferable.

Flexible is good..  However keep in mind that while KVP is nice
for XML, it's NOT nice for SQL.


       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available

More information about the gnucash-devel mailing list