RFC2: Date/Time proposal

[Charles Day]

On Wed, Jul 23, 2008 at 5:07 AM, Derek Atkins <warlord at mit.edu> wrote:

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

By my way of thinking, transactions without a user-entered time of day do
not have a time of day at all. A default time is set only temporarily for
viewing and sorting purposes, according to a preference. The defaulted time
is not a bona fide part of the transaction and does not need to be saved to
the data file, ever. The only reason for storing it at all is because you
said it was preferable to not change the file format. So IMHO changes to
preference #6 should affect defaulted transactions both past and future.

Otherwise you are not implementing "date only" functionality, but rather
"forced time entry".


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


Sounds fine, though on the first time through, any transaction in the file
with a time of day other than 00:00 is bug-affected and needs to be fixed.

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


OK. (Unless we want to allow time zone entry, a feature which doesn't seem
to be genuinely "on the table" at this point.)

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.


This is the part I disagree with (see above). I don't think the default
should be permanent. That isn't "date only" support. But even if you think
defaulted times should be permanent, there isn't a need to make this a
permanent choice NOW. We could let users decide this value for themselves
when time entry features are introduced, and do a one-time conversion.

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
>

-Charles