time_t - When does it break?

[Stuart D. Gathman]

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.