On 2005-02-03, Ashley Yakeley
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.
Yes, it is. Monotonic consistently scaled time is far more important than future conversions to UTC. If someone needs time precision down to the second for a time over six months in the future, they need to specify whether they want N seconds from now (use TAI) or a specific calendar time (in which case they should store that calendar time.
People need UTC time much more than they need TAI time, though TAI time is of course correct for intervals.
They need TAI clocks more than UTC clocks, but UTC calendars, as there is no TAI calendar. We have a clock with simple and nice properties, and a calendar with annoying properties to keep it in sync with Earth.
The simplest possible representation of UTC if you don't mind being wrong at leap seconds is something like POSIX time.
IOW, fundamentally incorrect.
The simplest possible correct representation of UTC is either a (days,ticks) struct, which is slightly more complicated for the kernel,
True, but the _kernel_ needn't know about the calendar, even to obey POSIX. All the conversions can be done in the userspace bindings to the system call. -- Aaron Denney -><-