time_t - When does it break?
Stuart D. Gathman
stuart at gathman.org
Thu Jul 17 14:10:23 EDT 2008
Charles Day wrote:
> The basic idea is that in an account register the user enters a date
> and time of day (or accepts the default time of day) in terms of that
> account's timezone. When you view that transaction in another
> register that has been set to a different timezone, the date and time
> is displayed accordingly. For example, if you specify July 7, 2008
> 13:03 in a UTC+11 register, then viewing that transaction in a UTC-7
> register would show July 6, 2008 18:03. (If I did the math right.)
Well, that approach obviously doesn't solve the date compatibility
issue. To even be usable, the register would have to display the timezone.
> There is no pretending involved. I suggest that GnuCash would write
> the timestamp to files in UTC, but only by converting first (July 7,
> 2008 02:03).
That makes the situation even worse than it is now by discarding the
timezone info in the datafile.
> GnuCash really could write the date and time to the file in any time
> zone, as long as the time zone was saved too.
That is what it does now. The current issue is how it handles
dates/timestamps in memory. The datafile is fine.
To beat the currency analogy to death, the way gnucash currently works
is like converting all monetary amounts to one gobal currency
preference, say USD. This mostly works, but your invoices in Pesos
don't add up! The "pretend localtime is GMT" approach is like storing
Pesos "as is" without converting. All the invoices add up, but whenever
dissimilar currencies are combined, the code has to be careful to
convert first. Converting requires that the currency was stored
somewhere else - perhaps in the customer record. This works, but
storing the currency with each amount is less error prone.
A simple workaround.
Since gnucash works fine within one timezone, why should it be fixed at
all? The only people to care are jetsetters who travel between
timezones and change the timezone on their laptop accordingly. One
workaround for jetsetters is to wrap gnucash in a script that sets the
TZ environment variable to a fixed value - say their home timezone.
This prevents all date problems and accurately records timestamps. (The
user has to remember to enter any time of day info in their home
timezone, and that timezone should be displayed in the UI as a
reminder.) The only thing not recorded is which timezone you were in
when the transactions were recorded. Big deal. So add "transaction
timezone" as a global preference, and the immediate problem is fixed.
If people actually need to track which timezone they were in, they
probably really want to track exactly *where* they were - not just the
time zone, and gnucash could be extended to record location.
More information about the gnucash-devel