RFC2: Date/Time proposal

Phil Longstaff plongstaff at rogers.com
Mon Jul 21 17:24:43 EDT 2008

Christian Stimming wrote:
> Am Montag, 21. Juli 2008 20:36 schrieb Stuart D. Gathman:
>> 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).
> Yes.
>> 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.
> Yes. I agree this is what we should do in the short term.
>> (Although I'd just use a date type.)
> Yes, this is what I agree should happen in the long term.

First of all, before we look at implementation, what *behavior* are we
aiming for?  What are the user requirements?

Secondly, my guess is that this wouldn't be before the 2.4 time frame.
I think the DBI/SQL backend is ready for more general trial, so this
feature might be implemented in that backend.


More information about the gnucash-devel mailing list