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)