time_t

[Charles Day]

On Thu, Jul 17, 2008 at 9:46 AM, Stuart D. Gathman <stuart at gathman.org>
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