Transaction timestamps are a design flaw (was: time_t)
stimming at tuhh.de
Thu Jul 17 04:20:56 EDT 2008
Am Dienstag, 15. Juli 2008 21:35 schrieb Derek Atkins:
> Quoting Graham Leggett <minfrin at sharp.fm>:
> > If I don't do this, transactions report themselves as being one day
> > early, so transactions on the first of the month suddenly appear on
> > the last day of last month, which sends my VAT returns into a spin.
> That's because transactions are set at midnight instead of, say,
> > I think this is being caused by dates that are actually dates and not
> > times, being stores as times.
> You think incorrectly.
> There are LOTS of reasons to store times in transactions. There ARE
> timestamps in the real world. And there are reasons that some people
> want to actually put time stamps into transactions, too (see bug #89439).
> I'm not saying that there isn't a bug here, just that your reasoning
> is flawed.
I disagree with Derek here. Instead, I agree transactions should store a
*date* and not a timestamp as the piece of information that is presented to
the user. And I agree it's a design flaw of gnucash that we don't have a
separate data type exactly for such a *date* as opposed to a timestamp.
(The "date_entered" [sic!] timestamp, on the other hand, describes the point
in *time* when this was entered, where a timestamp is the perfectly
I fully agree with Graham's reasoning here - I've seen my transactions
shifting through the days as I switched timezones, and it's a mess. I
disagree this issue would have gone away by using the noon timestamp, as
UTC+13 (or whatever) exists and has already been mentioned here.
One place that IMHO solves this whole date vs. timestamp issue correctly
(eventually) is the boost library and its date_time sub-library, see
http://www.boost.org/doc/libs/1_35_0/doc/html/date_time.html , where they even
enforce the distinction between dates and times quite rigidly through C++
constructor constraints. In effect, the programmer really has to think about
whether one wants a date or a time point here.
All financial bookkeeping that gnucash has encountered so far maps
transactions to one particular day. This is what the internal types should
reflect, and the fact that we don't do this is still a design flaw although a
very old one.
More information about the gnucash-devel