RFC: Timestamps/timezones proposal

Derek Atkins warlord at MIT.EDU
Fri Jul 18 14:29:05 EDT 2008


Graham Leggett <minfrin at sharp.fm> writes:

> Charles Day wrote:
>
>> Tell me how this proposal would cause "random" date changes. Only
>> the *display* of the timestamp changes, and only according to
>> settings that you pick yourself.
>
> Try this:
>
> Enter a transaction dated 1 March 2008 in an account with timezone
> UTC+02, with its split in a second account with a timezone of UTC.

Okay, so the transaction would have an internal timestamp of
"2008-03-01 12:00:00 UTC".  In UTC+02 this gets displayed as
2008-03-01.  It will also be displayed as 2008-03-01 in the
UTC-TZ account.

> Later, the user notices that in the second account, the transaction
> appears on 29 Feb 2008, goes "that's odd", and "corrects" the date to
> say 1 March 2008.

Nope, it will be 2008-03-01 in both accounts.

> Without the user knowing, the transaction on 1 March is now actually
> on 2 March 2008.

Nope.  See above.

[snip]

Having said all that, I'm beginning to believe that for the
POST Date I think it should ALWAYS be in UTC and always be
displayed as UTC, regardless of the local timezone.

Before you get yourself in a snit, let me explain what I
mean.

When *entering* a date, we take the entered string (e.g. 2008-07-18)
and create a UTC timestamp of 12:00:00 on that date in UTC.
So it doesn't matter that we're in UTC+14, we see that the
local date is July 18 so we create a July 18 noon-UTC timestamp.

When displaying a date, we take the UTC conversion of the
UTC timestamp and display it.

voila -- we now have "dates" using time_t.

-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


More information about the gnucash-devel mailing list