time_t - When does it break?

[Ian Lewis]

I kind of understand where Stuart is going with this. There are a lot
of parallels. The currency example is one. From a programming
perspective, storing strings without an encoding is another.
Essentially to know the real value you need to know another piece of
metadata.

Stuart,
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? 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?

Ian

2008/7/18 Stuart D. Gathman <stuart at gathman.org>:
> Charles Day wrote:
>>
>> 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.)
> Repeat after me: timestamps do not store date.  Timestamps do not store
> date.  Your own example shows that timestamps do not store the date.
> The date changes when the user changes timezone!!!  As you just said
> above:  "The time zone is only needed when converting to a date ...".
> That is precisely the problem.   The time zone is needed when converting
> to a date or time of day.  Is the problem that people don't think dates
> are important in accounting?  Then why have the user enter a date ???
>
>> 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.
> As long as only dates were ever displayed, that would work fine (other
> than being kludgy, complicated and slow compared to storing dates) .
> But some modules, like stock prices, need actual timestamps.  And
> displaying those in an arbitrary gnucash timezone would be highly
> confusing to the end user.
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>