RFC: Timestamps/timezones proposal

[Charles Day]

On Fri, Jul 18, 2008 at 12:36 PM, Stuart D. Gathman <stuart at gathman.org>
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