time_t - When does it break?
Mike or Penny Novack
stepbystepfarm at mtdata.com
Fri Jul 18 06:39:30 EDT 2008
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
>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? .........
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
More information about the gnucash-devel