RFC2: Date/Time proposal

[Charles Day]

On Mon, Jul 21, 2008 at 11:36 AM, Stuart D. Gathman <stuart at gathman.org>
wrote:

> On Mon, 21 Jul 2008, Derek Atkins wrote:
>
>  Does it really matter?
>>
>> First, we're assuming that we ARE going to implement that feature,
>> which we don't necessarily need to.
>>
>
> The current datafile format has a problem when the user switches
> timezones.  While the saved timestamps are restored correctly, thanks
> to the included timezone, the *dates* change.  The only work around
> at the moment is to load gnucash through a script which sets the TZ
> environment variable to a fixed value (the value used to start the
> gnucash datafile).
>
> It has been proposed that gnucash use a fixed timezone internally - e.g.
> UTC, and ignore the system timezone when the user enters a date.  This is
> great (except I'd use an actual date type), and fixes the problem for
> new gnucash datafiles.  But now loading old datafiles changes the dates.
> Since the original timezone was saved, this can be "fixed" by setting the
> date to the date in the original timezone.  This loses the original
> time of day info, but then the time of day info was just a constant
> anyway.  Dates saved with a new gnucash would all have the UTC timezone.
> (Although I'd just use a date type.)
>

Making time zone a constant fixes the current bug. For data files that are
already sick, it would be very nice to offer a tool to fix them. The
algorithm doesn't seem that hard. All transactions should currently have a
time of day of 0000 in the current, OS-specified time zone.  If they don't,
they were affected by the bug and need to be fixed. In some cases it would
be necessary to ask the user to make the call, but in lots of cases it
wouldn't. For example, I believe Graham said that he moved two hours to the
West and is now on UTC. So his old transactions would now be in his file as
22:00. So he either moved two hours West or 22 hours East. Since his current
time zone is UTC, the 22 hour East move is ruled out (since UTC+22 doesn't
exist), so GnuCash could push all transactions having 22:00 ahead by 2 hours
to fix them. (Perhaps further discussion of how to fix existing data should
have its own thread.)

Now, there is talk of an optional feature to enter actual time of
> day on transactions (has anyone asked for this?).  The obvious way
> to distinguish between transactions where time of day was entered and
> those where just a date was entered is to use a date type for those
> transactions where just a data was entered.  But, since this isn't
> popular, another alternative is to use a magic timezone for dates - e.g.
> GNC.  The GNC timezone would be just like UTC, except it signifies that
> only a date was entered, and the time of day info should be ignored (or
> set to some user preference like 12:00).
>
> 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.)


> UI people should
> think long and hard before deciding to "convert" entered timestamps
> from one timezone to another.  All entered timezones should be saved,
> and reproduced when the datafile is rewritten.  It is not enough to convert
> to time_t - that doesn't preserve the timezone.  You need time_t +
> timezone.
> If the conversion is in response to some gnucash user change like changing
> a
> timezone associated with a register, that should affect only the display in
> that register.  Users could see the dates change, and maybe decide to put
> it back...
>
> --
>              Stuart D. Gathman <stuart at bmsi.com>
> 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