On Thu, Jul 17, 2008 at 9:46 AM, Stuart D. Gathman <[EMAIL PROTECTED]> wrote:
> 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 > perspective > > > 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). > > Stuart, 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? Thanks, Charles _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel