On Friday 11 February 2005 11:54, Marcin 'Qrczak' Kowalczyk wrote:
> OTOH TAI is suitable for exact measuring the length of timespans, and
> for nothing else. It's not suitable for converting timestamps to/from
> yyyy-mm-dd hh:mm:ss, until a system-wide automatically-updated leap
> second table is designed and implemented, unless you don't mind having
> to release, download and install a Haskell compiler and recompile all
> programs every 6 months.
I don't understand why this should be necessary. Obviously, the "current" leap
second table is something that changes with time. Thus, whatever method is
used to maintain it (automatic/manual update; system wide, aplication
specific, or compiler specific table), gaining access to it is necessarily
going to be an IO action. Of course, a system-wide automatically-updated leap
second table would be ideal, but a manual update (for instance by downloading
a file to a language/compiler/version dependent location; perhaps even
manually editing the file) could be used as an approximation, as long as the
OS doesn't provide the ideal solution.
In any case, the programmer need not be aware of the specific method. All we
need is an IO action
getCurrentLeapSecondTable :: IO LeapSecondTable
whose exact working should be defined on installation of the
compiler/interpreter, when system properties can be checked to determine
- whether system clock is POSIX, UTC, or TAI
- whether there is a system wide leap second table
The table returned should know its limit (i.e. the point in time, up until
when it can correctly convert between UTC and TAI). Thus the UTC/TAI
conversion function can indicate in its result, whether a precise conversion
was possible (i.e. time is prior to table's expiration date) or not. In the
later case, it would make sense to return an approximation based on the
assumption that no future leap seconds will happen (other schemes are
possible, of course).
Ben
--
"The CIA is Wallstreet. Wallstreet is the CIA." (Mike Ruppert)