time_t - When does it break?

[Charles Day]

On Thu, Jul 17, 2008 at 11:10 AM, Stuart D. Gathman <stuart at gathman.org>
wrote:

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

I'm not following the bit about "doesn't solve the date compatibility
issue." Could you explain? (Sorry if you have explained earlier.)

Personally, I wouldn't need the timezone displayed in the register because I
have few enough variations that I would know which registers are showing
which timezones. But sure, the timezone could be displayed somewhere (status
bar, maybe).

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

No, the transaction timestamp is stored, denoting the precise point in time
at which the transaction posted. The time zone is only needed when
converting to a date or time of day, and for that you have the user's
preferences (a default display time zone, a time zone per account register,
and a reporting time zone.)

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

Having a preference for a single time zone just means ignoring the OS time
zone. If we were going to do this, then why even offer users an option, or
save it? The GnuCash developers could just pick a time zone at random and go
with that.

-Charles