On Fri, Jul 18, 2008 at 12:36 PM, Stuart D. Gathman <[EMAIL PROTECTED]> wrote:
> Charles Day wrote: > >> Under what circumstances would an end user ever choose the option >>> "randomly >>> change the dates on my transactions when I change the timezone on my >>> machine"? >>> >>> >> 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. >> >> > The key is that the register would display date,time, AND TIMEZONE. The > timezone lets the user recognize that 11:23PM Jul 13, 2008 EDT is really the > same as 03:23AM Jul 14, 2008 BST (or whatever - I didn't actually look up > BST). TIMEZONE is what disambiguates 2:00AM EDT from 2:00AM EST when the > clock jumps back. TIMEZONE is crucial data when using timestamps - even > within a single time zone, if events in the wee hours are important. I > worked on a security guard monitoring system, and even though all events > were within a single timezone, display had to include timezone to > distinguish between EST/EDT. > > If the register displays date only, but you want to store timestamps > instead to keep timestamp functionality available, then you must store the > timezone also - even in memory. A timestamp without timezone is like > Incredible without Frozone - no I mean you can't recover the date entered by > the user. Storing or hardwiring a fixed timezone for date only operation is > acceptable if documented. > For those who want date only operation, or those who want to be able to do time of day entry, that's exactly what I would say... don't allow the timezone to float. If GnuCash picked a single time zone and stuck to it internally, users wouldn't need to know, see, or care about it. It seems to me that the current bug in GnuCash is allowing the time zone to vary at the whim of the operating system. For users who want to not only enter time of day, but have account registers with different time zones, the time zone could be allowed to float in the way I proposed. Heck, this "multi-time-zone" feature doesn't even need to get implemented, since no one seems to have ever asked for it. This was just taking the use of timestamps to its logical extreme. I might use a "multi-time-zone" feature myself on a few accounts, because it might actually simplify entry for me, but I've never been offered that feature before. So I am quite used to fudging the date on transfers across the date line. -Charles _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
