ketil+haskell at ii.uib.no
Wed Jan 26 14:27:17 EST 2005
Peter Simons <simons at cryp.to> writes:
> I think that's true, but not being able to express a date in
> the future is a rather serious limitation, IMHO. If you want
> to do that (and you do), then not all time systems are
> equally good.
The flip side of the coin is of course being unable to specify time
differences with certainity in the future.
> A bank, for example, can't store its financing data in TAI,
> because TAI knows only the difference between two points in
> time. Between now and some day in the future, exactly 'n'
> seconds will pass.
I think the bank should use a system that lets it specify, in an
unambigous way, days, if that's what matters. Counting seconds
shouldn't be a matter of concern.
So we need two systems, and if the correspondence between them
(e.g. which_day_is_this :: Time -> CalendarDay) gives the wrong answer
for a second for people who update their systems more rarely than once
a year, well, they get their interest (or mortgage) one second late in
the worst case.
> Therefore these applications really need to store
> _calendar time_, which would be UTC et all.
I don't think UTC seconds is the right thing either, but some real calendar
type. I would like to specify "the first day of each month", not intervals
of x seconds, y seconds, then x seconds again...
>> Assuming milliseconds (is this reasonable?):
> IMHO, a good choice to store distance in time is:
> type TimeDiff = (Integer, Float)
It would perhaps be nice if the interface provided a way to determine
the resolution of the timer -- a guarantee of a minimum value of
change, I guess.
If I haven't seen further, it is by standing in the footprints of giants
More information about the Libraries