cedayiv at gmail.com
Thu Jul 17 13:00:08 EDT 2008
On Thu, Jul 17, 2008 at 9:46 AM, Stuart D. Gathman <stuart at gathman.org>
> Nathan Buchanan wrote:
> > I agree that the 00:00 timestamp is a bug, but the 12:00Z or 10:01:00Z
> > simply works around the bug for 90% of the use cases. From the
> Not only that, but if you force the time of day in each timestamp to
> 12:00Z, then you no longer have a timestamp, but a complicated and
> difficult to use date type. You can't even subtract these ersatz "date"
> types to get days between dates. (No dividing by 24*60*60 doesn't work
> - don't forget DST, etc).
> There is *far* less code overall to just store dates (ideally a day
> number of some sort) where you want dates (i.e. where you would force
> the TOD to 12:00), and store timestamps where you need timestamps (stock
> prices, etc). I've been dealing with this issue for 30 years, and seen
> the same mistake made over and over. Similar to trying to do accounting
> with binary floating point. Yes, you can make it work by rounding every
> other line of code. But it is butt ugly, slow, and error prone. And
> usually doesn't actually work in any given application (invoice totals
> sometimes off by a penny).
I would be interested in your reaction to my RFC on a timestamp
implementation. Other than ease-of-use issues, is there a situation in which
the RFC's proposed way of using timestamps would be detrimental compared to
using a date alone?
More information about the gnucash-devel