time_t - When does it break?

[Mike or Penny Novack]

Ian Lewis wrote:

>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? .........
>
Not exactly.

I believe (from my own experience) that what Stuart is trying to say is 
that for ordinary bookkeeping/accounting purposes transactions occur on 
a DATE. That for the legal purposes of "when was payment received" (so 
called "constructive delivery") all that matters is the date. That a 
payment made on 07/18/08 is before any made on 07/19/08 but one made at 
0700 on 07/18/08 is NOT "before" one arriving at 0800 on 07/18/08

There may indeed by (other) purposes where the time is meaningful.

But just where is this time coming from? What is the source of this 
data? When I enter a transaction into GnuCash I have to specify a date 
-- the time component filled in for that date (when stored as time) 
comes from where? Remember, the real time at which the bookkeeper enters 
the transaction bears no relationship to the date of the transaction 
itself. Since NO time data was entered the only thing that would be 
correct coding was for the SAME (constant) time of local day to be used 
in all instances. If the "time of day of the date upon which the 
bookkeeper enters the data" is used that's dead wrong, implies assigning 
a before/after that has nothing to do wit the transactions themselves, 
just the order in which the bookkeeper pulled them from the stack.

Michael D Novack, FLMI