RFC2: Date/Time proposal

[Derek Atkins]

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

>     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.
>
> What I mean is that if users were able to do time entry, and we stored the
> time but not a "user-entered" flag, then we wouldn't be able to tell which
> times were user-entered. So when you changed preference (6) it could only
> apply to new transactions.

I think changing the time in preference #6 should only affect new
transactions regardless!  Preference #6 should never, IMHO, make
changes to already existing transactions.

So here's what I'm thinking:

1) Timestamps are always stored in UTC.  But we do a conversion on entry
   where we take the /local/ date and make a UTC timestamp out of it.
   So if it's 2008-07-23 in localtime, we create a UTC timestamp of
   2008-07-23 12:00:00 (even if we're in a locale where it's NOT the
   same date in UTC).  E.g., if we're in GMT+2 and it's 0100 then in
   GMT it's still a day earlier, but we should use the local "today"
   date when constructing the timestamp.
2) Dates (and times) are always displayed in UTC.  So when we see a
   timestamp of 2008-07-23 12:00:00 (UTC) we display it as 2008-07-23
   (even if we're in GMT+14 or some other timezone that would put that
   timestamp into a different date bracket).
3) Timestamp defaults to 1200 (UTC).  Eventually we could add a preference
   to allow users to change the default timestamp, but that setting would
   only affect new transactions.
4) Eventually we could add a ToD setting, to let the user choose the
   time of day of a transaction.  This ToD is always stored and
   displayed as UTC.  By making the default 1200 it makes it really easy
   to move transactions in front of or behind others without having
   to adjust anything.
5) We need a procedure to determine that a data file is using old
   timestamps and ask the user if they want to update their datafile.

Note that this does NOT change the format of the data file.  We
just change the semantics.

Also note that the process in #5 would create a semantically
backwards-incompatible change to the data file...  But I think
this is fine.

Finally, pretty much ALL of this work is in the UI.

Comments?

-derek

-- 
       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