time_t

[Graham Leggett]

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 
saving switchover.

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 
now.

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.

Regards,
Graham
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3287 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20080715/5a4ecc3b/attachment.bin