time_t - When does it break?

Stuart D. Gathman stuart at gathman.org
Fri Jul 18 15:16:07 EDT 2008

Ian Lewis wrote:
> I'm curious though, and maybe you can fill me in, is the reason that
> the timestamp is important that, from an accounting standpoint, the
> transaction occurred on the day (in the timezone) that it was entered
> into the register? Meaning that the date is June 6 because it was
> entered in Timezone A even though that same time was June 7 in
> timezone B?
The date is important because it is the date the user entered.  I for 
one, don't like my accounting data (apparently) changing under my feet.  
I'll say again that gnucash is fine the way it is now, provided you 
don't change timezones.  To support multiple timezones with just dates, 
the obvious solution is to just store dates.  To support multiple 
timezones with timestamps, you could store just a date when the user 
enters just a date.  Or you could store timestamp (with current or 
12:00Z time of day) plus current timezone.  The current timezone allows 
the date the user entered to be recovered from the timestamp.  The idea 
of making time of day part of the register could be useful - but not for 
me.  And, I suspect, not for most home users.  But if it's optional, it 
could be interesting.  After all, Fedora comes with all kinds of neat 
high powered enterprise software that most home users wouldn't 
recognize.  Having powerful tools available is never a bad thing. 
> So it's June 6 regardless of timezone. In other words, the
> timezone in which it was entered needs to be stored to figure out what
> day it was entered? Otherwise, wouldn't the local timezone be enough
> to serve as metadata when converting to a date?
Timestamp (time_t) plus time zone where timestamp was entered is 
sufficient to recover the date.  Timestamp plus some random time zone 
where date is viewed recovers the date entered +/- 1 day.

More information about the gnucash-devel mailing list