RE: System.Time.Clock Design Issues
On 03 February 2005 13:01, Ashley Yakeley wrote:
It's true that POSIX is an inherently wrong representation of UTC, as it is wrong at leap seconds. The trouble is, what you are suggesting is a type that is wrong in a much more complicated way: it starts off as a correct representation of TAI, and turns into a representation of UTC that is also wrong at leap seconds.
Let us suppose we have a system clock that keeps POSIX time, and a Haskell function, getClockTime, that returns the current ClockTime you are suggesting. I compile a program that calls this function.
At first getClockTime returns the correct TAI time, which can be converted into the correct UTC time. Then, in two years' time, a leap second is announced. During the leap second, the system clock is stepped, and getClockTime returns the wrong TAI time converted to the wrong (by up to a second) UTC time. After the leap second, getClockTime continues to return the wrong TAI time, but it is converted to the correct UTC time.
Actually you'd probably get a correct UTC time, because the conversion would be done by first converting to POSIX time, and then asking the C library to convert to UTC. The errors cancel out. 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. 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 :-) Cheers, Simon
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
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 -><-
Aaron Denney
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.
"Future" becomes "past" as time passes. IMHO it's more important to have rules which don't change every few months than to have a uniform clock speed. The choice "let time_t represent TAI" would not have been a viable alternative for POSIX without introducing some machinery for maintaining the leap second table, because people use local time which is derived from UTC for displaying the time. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/
In article
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.
Well, we already have that with the clock() function, which returns something like CPU uptime or process time and is not affected by leap-seconds I believe. -- Ashley Yakeley, Seattle WA
The most basic or at least the most obvious function in a time library is one that gets the current time. What is its return type? getCurrentTime :: IO ??? There seems to be consensus that it should be some kind of encoding of UTC rather than TAI. If you don't mind the hiccups, POSIX time is the simplest way to (mostly) encode UTC. The simplest _correct_ way is a (days,ticks) pair. A third alternative would be broken-down Calendar time, with year, month, day etc. What's the best choice for getCurrentTime? -- Ashley Yakeley, Seattle WA
Ashley Yakeley wrote:
The most basic or at least the most obvious function in a time library is one that gets the current time. What is its return type?
getCurrentTime :: IO ???
The only way to find out the current time is to ask the system for it, so, following the rule of avoid-unnecessary-conversions, I think it boils down to what the system provides. My impression is that it doesn't reliably provide us anything. Therefore we should omit getCurrentTime from the library. :-) Or, more pragmatically, have it return OSTime, and provide broken-by-design conversions from that to everything else. OSTime would presumably be struct timeval on Unix, and FILETIME or SYSTEMTIME on Win32. -- Ben
participants (5)
-
Aaron Denney -
Ashley Yakeley -
Ben Rudiak-Gould -
Marcin 'Qrczak' Kowalczyk -
Simon Marlow