RFC: Timestamps/timezones proposal
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
> 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.
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
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 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