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 <[EMAIL PROTECTED]> wrote: > From: Graham Leggett <[EMAIL PROTECTED]> > Subject: Re: RFC: Timestamps/timezones proposal > To: "Charles Day" <[EMAIL PROTECTED]> > Cc: "GnuCash Devel" <gnucash-devel@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@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
