RE: System.Time.Clock Design Issues
On 03 February 2005 11:30, Ashley Yakeley wrote:
Sure, we could get rid of it entirely and rely on CalendarTime everywhere. This is the trade-off I see:
* POSIX time
not already necessary fast retrieval from system clock fast calculation of time differences and offsets independent of time-zone
* Structured calendar time
already necessary anyway slow retrieval from system clock slow calculation of time differences and offsets may be dependent on time zone
The time zone issue is a red herring. You can use UTC calendar time exclusively if you want. I disagree that calendar time has slow calculation of time differences and offsets: - for time differences measured in units of minutes and larger, the broken down calendar time is easier to do calculations on. - for units smaller than a minute, doing calculations with either of them might give wrong results. You need to use TAI time instead. I think you're suggesting that we allow calculations in units of seconds on POSIX time and calendar time, and just document that they don't take into account leap seconds. I'd rather say that you can do accurate calcuations on TAI time, but conversions might be wrong. Second-based calcuation on calendar time can be done by converting to TAI to do the calculation. You can also do second-based calculations ignoring leap seconds on a calendar time if you want.
In summary:
Using TAI with a limited leap-second table is trading a simple kind of brokenness (all leap seconds) for a complicated kind (future leap seconds after some date).
That's a good way to put it. I think TAI + calendar time covers all the bases, except that you can't do *really fast* second-based calculations that ignore leap seconds. But (a) I don't think this is something we should encourage and (b) I don't think we should expose an inherently wrong representation of time (i.e. POSIX). For people who want to measure time differences between two points, the library API should encourage them to use units of minutes and larger, which are independent of leap seconds. Cheers, Simon
On Feb 3, 2005, at 04:09, Simon Marlow wrote:
That's a good way to put it.
I think TAI + calendar time covers all the bases, except that you can't do *really fast* second-based calculations that ignore leap seconds. But (a) I don't think this is something we should encourage and (b) I don't think we should expose an inherently wrong representation of time (i.e. POSIX).
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. What we end up with is a type that no longer represents TAI. Instead, it represents a fixed offset to UTC. The only way to get anything correct out of it is to convert it to UTC, though even then, it won't be correct during a leap second -- exactly like POSIX time. It's the same if we wish to measure time offsets. Supposing I want to know how long something takes, of the order of seconds. I call getClockTime at the beginning and end of the interval, and subtract one from the other. This will be correct most of the time, but if there was a leap second in between, which the library cannot predict if my program was compiled years ago, then the calculation will be off by a second. Again, this is exactly like POSIX time. So what we have is a type that behaves like TAI for the past, but POSIX time for the future, even though it's supposed to be TAI. Surely it would be better to simply use POSIX time? -- Ashley Yakeley, Seattle WA
So what we have is a type that behaves like TAI for the past, but POSIX time for the future, even though it's supposed to be TAI. Surely it would be better to simply use POSIX time?
Also, if we ever do manage to extract real TAI from the system clock and use that for getClockTime, the situation is much worse: after a leap second, obtaining the UTC time (the most basic requirement of a time library) will be off by a second. -- Ashley Yakeley, Seattle WA
The most recent messages motivated me to consider avoiding both POSIX and TAI
time.
CalendarTime will provide a way to calculate date differences in whole days,
and to add n days to a date. This should account for leap years. Likewise
CalendarTime will provide a way to calculate time differences in seconds, and
to add/subtract n seconds. It would seem to follow that this should account
for leap seconds.
"Simon Marlow"
You can still do accurate calculations on calendar times in the future, and that's what matters.
However, the relationship between seconds and the future calendar is not known. A specific second such as 2005-12-31T23:59:59 may turn out not to occur. So even CalendarTime is not safe from leap seconds. On 2005 February 03 Thursday 08:00, Ashley Yakeley wrote:
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.
Until there's a system call that provides up-to-date information about leap seconds, the above-quoted scenario can occur. Since future conversions between calendar time and TAI are likely incorrect, how about raising an exception? A TAI version of getClockTime would, in compiled code, go stale and after a few months and start raising an exception. As a programmer, that would steer me almost all the time to use a POSIX representation, and to do CalendarTime difference calculations without accounting for leap seconds. Here are my leanings on some of the points of discussion. (1) POSIX time is useful primarily if you need to be close to the OS or to NTP time. For general purposes I would avoid it unless I was sure I wanted to calculate with seconds and didn't care about leap second inaccuracies. (2) CalendarTime is the most useful form for applications. It should try to be accurate in relation to leap seconds, but should not raise exceptions due to e.g. (1) an incomplete leap second table or (2) reference to a second which did not occur such as 2004-12-31T23:59:60. (3) Some of the messages in this thread exhibit a tendency to reduce all times and dates to a single representation, e.g. integral POSIX seconds + fraction. That's a dead end. There's complexity in the conversions which means that a program should make conversions sparingly and use a representation/calendar that's close to the program's need. (4) TAI is an important "calendar". It can specify future times that, for scientific purposes, can't be matched by CalendarTime. The necessity for TAI goes hand in hand with the impossibility of converting between future TAI times and future calendar times. Nearly all programs made for home or business do not need TAI. It is not properly supported by POSIX or Windows.
Simon Marlow wrote:
The time zone issue is a red herring. You can use UTC calendar time exclusively if you want.
I'm not entirely sure what you mean by that, but you need local
calendar times for date arithmetic, e.g. "one month from now":
$ export TZ=Asia/Tokyo
$ date -d '2005-02-28 23:00 UTC'
Tue Mar 1 08:00:00 JST 2005
$ date -d '2005-03-01 08:00 JST'
Tue Mar 1 08:00:00 JST 2005
$ date -d '2005-02-28 23:00 UTC +1month'
Tue Mar 29 08:00:00 JST 2005
$ date -d '2005-03-01 08:00 JST +1month'
Fri Apr 1 08:00:00 JST 2005
--
Glynn Clements
participants (4)
-
Ashley Yakeley -
Glynn Clements -
Scott Turner -
Simon Marlow