minfrin at sharp.fm
Tue Jul 15 16:29:47 EDT 2008
Derek Atkins wrote:
>> 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 didn't say that *all* timestamps were unnecessary, what I said was
that dates that are actually dates, and not times, are being stored as
times, and that this is incorrect.
For an example, look at the date entered in a transaction. The UI only
allows you to choose a year, a month and a day, and because of this, you
should only store a year, a month and a day.
A date represents a fixed distance in time, from midnight on the
previous day, to midnight on the same day, and width of this distance
could be affected by all sorts of things like leap seconds and daylight
In contrast a timestamp represents a fixed point in time, and as you
vary the timezone, the date could change from yesterday, to today, or
today, to tomorrow.
If you mix the two up, you get the sorts of weird behaviour that we have
It is perfectly reasonable to store timestamps for certain things. The
point in time at which the transaction was captured should be a
timestamp, not a date.
But if you ask the user for a date (a range of time approx 24 hours in
length), don't change that to a timestamp (a fixed point in time since
the epoch), it just generates bugs.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3287 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20080715/5a4ecc3b/attachment.bin
More information about the gnucash-devel