RFC: Timestamps/timezones proposal

[David T.]

Charles, I believe Graham is right on this. I can easily see the end-user scenario that he outlines, and I agree with him that the transaction date is a DATE. All the confusion about UTC, timezones, account settings and the such GO AWAY if the transaction is a date. Moreover, throughout all of this discussion, I haven't seen a compelling reason to use a timestamp in this context.


--- On Fri, 7/18/08, Graham Leggett <minfrin at sharp.fm> wrote:

> From: Graham Leggett <minfrin at sharp.fm>
> Subject: Re: RFC: Timestamps/timezones proposal
> To: "Charles Day" <cedayiv at gmail.com>
> Cc: "GnuCash Devel" <gnucash-devel at gnucash.org>
> Date: Friday, July 18, 2008, 10:18 AM
> 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.
> 
> 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.
> 
> Without the user knowing, the transaction on 1 March is now
> actually on 
> 2 March 2008.
> 
> Try this:
> 
> Create a new account. The account is created with the local
> timezone as 
> a sensible default. User thinks nothing of it and creates
> an account in 
> timezone UTC+02.
> 
> Fast forward some time, change your timezone in the mean
> time. Create a 
> new account. The account is created with the local timezone
> as a 
> sensible default. User thinks nothing of it and creates an
> account in 
> timezone UTC.
> 
> User encounters the first problem above and goes huh?
> Wastes lots of 
> time, posts it as a bug, and then someone tells the user
> "oh it's 
> supposed to work like that".
> 
> User ditches gnucash.
> 
> > You ask the impossible. Using a date alone doesn't
> guarantee freedom 
> > from date-related bugs either. Considering the present
> state, switching 
> > to a date alone would actually be a larger coding
> effort, and therefore 
> > probably more bug prone.
> 
> You misunderstand the risk being faced.
> 
> If a timestamp is used, it means that every single piece of
> time related 
> code, must correctly respect the account timezone, at all
> times moving 
> forward during development.
> 
> As soon as *one* developer at *any* time in the future
> makes *one* 
> mistake with regards to the timezone, the bug is back.
> 
> The core premise behind defensive coding is choosing coding
> strategies 
> that make it very difficult to make mistakes.
> 
> It is difficult to get a date wrong, because "1 March
> 2008" is always 
> and without exception equal to "1 March 2008".
> "2 March 2008" is always 
> and without exception exactly one day after "1 March
> 2008".
> 
> If you want to make life difficult for yourself and for end
> users, stick 
> with the timestamps.
> 
> Regards,
> Graham
> --_______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel