But I agree with the rest of what you say. Basically, providing TAI time is problematic because we can't implement it correctly, for future times, on systems that only provide POSIX time.
Yes. Any solution that involves compiling in a leap-second table is going to run into trouble when the table becomes out of date.
At this point I'm not sure what is best, I'm still quite disturbed by the idea of basing the definition of the Haskell Time library on what is basically a mistake in the definition of POSIX :-)
It's not clear what POSIX should have done. People need UTC time much more than they need TAI time, though TAI time is of course correct for intervals. The simplest possible representation of UTC if you don't mind being wrong at leap seconds is something like POSIX time. The simplest possible correct representation of UTC is either a (days,ticks) struct, which is slightly more complicated for the kernel, or something that's days*86401+seconds, i.e. with a gap for a leap second every day, which is a nightmare for time differences. -- Ashley Yakeley, Seattle WA