RFC2: Date/Time proposal

[Stuart D. Gathman]

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.)

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.  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.