On Mon, Jul 21, 2008 at 7:54 PM, Stuart D. Gathman <[EMAIL PROTECTED]> wrote:
> On Mon, 21 Jul 2008, Charles Day wrote: > > If the time of day entry feature is ever implemented and used, entered >>> timestamps would have the timezone for the time entered. >>> >> >> Under this proposal, the time zone is constant. Users do not get an option >> to specify time zone when they enter a time of day. So the time zone >> constant doesn't need to be saved in the data file. (However, doing so >> would >> do no harm.) >> > > Without the timezone, you can't enter all times of day unambiguously. > Once a year, the DT 1/2 to 2 hours after 2am are aliased to the > same period in ST. Without at least the ST/DT flag, you can't unamiguously > enter the time of day (unless you use something other than > localtime - which has its own problems). Yeah, I know, it took me months > to > explain this to the guard monitoring people also. > > Why this resistance to timezones? You want simple? Just store the date. > Yes, localtime is messy and complicated, but the way people tell time in > these > jet setting times involves HH:MM:SS and TIMEZONE. Actually, localtime is > not > that complicated. You want to store/display localtime, just don't forget > the > timezone. Unless the data will only ever be used from one locale. (Yeah, > right. I've heard those "X will never, ever happen" stories from customers > too. There is a grim satisfaction in seeing their sheepish look when X > happens. Especially, when I've already coded the hooks for X.) > Why this resistance to timezones? That's what I wondered after responses to the first RFC's "multi-time-zone" features argued that it would confuse users. And since no one had asked for timezone entry anyway, I left that out of this proposal to simplify things. However, if I understand your suggestion, you are now suggesting that a register would display a time zone for each transaction. Wouldn't you be confused if a transaction entered with a date of "Jan 2, 2008" appeared earlier in the register than one with a date of "Jan 1, 2008"? Because if you enter Jan 2, 2008 06:00 UTC+18 on one transactions, and then Jan 1, 2008 13:30 UTC-7 on another, that's what you'd see (since Jan 1, 2008 13:30 UTC-7 actually occurs after Jan 2, 2008 06:00 UTC+18). > > -- > Stuart D. Gathman <[EMAIL PROTECTED]> > Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154 > "Confutatis maledictis, flamis acribus addictis" - background song for > a Microsoft sponsored "Where do you want to go from here?" commercial. > -Charles _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
