Time

[Ketil Malde]

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.

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants