"Udo Stenzel"
The way I see it, both worlds almost never intersect, the only contact points are formatting time stamps and converting the current system time to calendar time.
These "only" points are the problem.
Assume the system provides UTC or POSIX time or something like that. Then our time stamps will still work, as they are still monotonically increasing. Nothing fails, only the conversion to calendar time will be off by around 20 seconds. So what?
If Haskell programs interpreted the current time and timestamps differently than all other parts of the system, shifted by 20 seconds, this is unacceptable.
If these few seconds matter, the offset could still be "configured away", and who cares if it isn't reliable or exact, the system time was broken to begin with.
It was not broken. Yes, it would be better if the system clock ran in TAI, and there was an automatically updated system-wide leap second table kept current, and it was supported by the C library and by NTP clients. But it is not the case.
Therefore, TAI + calendar + (optional) a fixed offset.
What am I missing?
That you don't know the correct offset. If a program begins miscalculating the time when it's run 6 months after the Haskell compiler it was compiled with was been updated, and thus programs compiled using different versions of the compiler interpret the same timestamp differently, this makes no sense. The problem with supporting TAI is that its relation to UTC is not known far in advance, and it is UTC which is shown to users and distributed by NTP and manipulated by all other programs. TAI runs smoothly but it's unimplementable. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/