Transaction timestamps are a design flaw (was: time_t)

[Christian Stimming]

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,
> noon.
>
> > 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 
reasonable representation.)

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.

Regards,

Christian