Time

[Keean Schupke]

Peter Simons wrote:

>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. If that day is in the sufficiently
>distant future though, your mortgage repayment won't be due
>on April 1st some year, but on March 31st a second before
>midnight. Therefore these applications really need to store
>_calendar time_, which would be UTC et all.
>  
>
But a computer cannot count calendar time unless it knows the
leap-seconds in advance forever... So the computer must count in
TAI. If you want to set a reminder event in the future (say an
alarm to go off at a specific time), then you must convert the counted
time (TAI) to localtime (in which the event would logically be stored for
the reasons you gave above)...

>You can map TAI to calendar time iff that date is in the
>past or in the near future. (I think leap seconds are
>announced at least a year before they occur or so.) That
>makes TAI unsuitable as an internal representation for most
>applications.
>  
>
So, the computer counts time in TAI, but stores events in the calendar in
which the user specified the events...

>
> > Assuming milliseconds (is this reasonable?):
>
>IMHO, a good choice to store distance in time is:
>
>  type TimeDiff = (Integer, Float)
>  
>
Floats do not give arbitrary precision... infact certain times
(like 1ms exactly) may not be representable at all!

    Keean.