John Meacham writes:
We should define the ClockTime to be in terms of TAI to the best of the systems ability. at worst, we subtract 20 seconds from posix time, this would be infinitly better than not knowing whether ClockTimes are TAI or posix and whether we can safely subtract them or do anything interesting with them.
Ok, but I don't understand why subtracting 20 seconds from POSIX time would be any better - that doesn't fix the fact that the scale is missing leap seconds, does it? You still can't do arithmetic on it and get meaningful results. I think I understand the problem. It is this: Many systems run their clocks on POSIX time_t. We could reconstruct TAI time from time_t by adding leap seconds, except around the actual time of a leap second. Around the time of a leap second, the NTP daemon will be adjusting the system clock backwards, and we won't be able to tell what the correct time is. Furthermore, we don't know whether the system is running on POSIX time_t, or "correct" time_t. libtai assumes a "correct" time_t. (this in itself is evidence that we should too). On a system with glibc, you can set your system time to "correct" time_t, by setting TZ to something like "right/GMT" (try it), and you also have to configure ntpd to do the right thing (I've no idea how to do this). On a system configured like this, our ClockTime will automatically be TAI-based, there's no need for leap-second tables. I suggest this is the way we should go - users who really need a correct ClockTime should configure their systems appropriately. So, we could either (a) Try to reconstruct TAI time from the system time, and accept that it will be wrong around the time of a leap second. We'll need a way to tell the library whether the system time is POSIX or not. Perhaps: systemTimeIncludesLeapSeconds :: Bool -> IO () (b) Accept whatever the system tells us. On a correctly-configured system, you get a TAI-based ClockTime, otherwise you get a POSIX-based ClockTime. (c) Or we can ditch the whole idea. I vote for (b). (I'll leave the other points in John's message until we've sorted this out, but they won't be lost). Cheers, Simon