RE: System.Time.Clock Design Issues

newer
RE: System.Time.Clock Design Issues

Bayley, Alistair

3 Feb 2005 3 Feb '05

10:14 a.m.

I'm a bit worried that I'm not keeping up with this, so I'd like to clarify some points for my own benefit: === The current time === - UTC/POSIX/CalenderTime are isomorphic, and represent some idealised notion of time where leap seconds don't exist i.e. a day always has duration 23:59:59. - Most (all?) system clocks return UTC. They may slow down around leap seconds to support this - is this behaviour only seen on systems with NTP? - It's not possible to simply get the number of actual ticks since some epoch; the OS time function may slow down for leap seconds and we can't avoid this. - This means TAI time can only be calculated accurately when we have the full leap second table available. === Durations === - Duration calculations are feasible for UTC at any point, as they're idealised. - Duration calculations are accurate for TAI only where we have the full leap second table, again. - Timing an event using the system timer where the event duration encompases a leap second will be inaccurate. - The duration between times A and B, where A->B encompass a leap second, will be different between UTC and TAI: UTC will not count the leap second, while TAI will include the leap second. - The duration between A and B, where both A & B are in the future (now + 6 months), will be the same in TAI and UTC because with TAI we won't know when the leap seconds are, so we assume and idealised calendar. Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

Show replies by date

Keean Schupke

3 Feb 3 Feb

10:59 a.m.

New subject: System.Time.Clock Design Issues

It seems other people dont like UTC either. NIST is working towards NTPv4 which will support the distribution of TAI. (By the way it appears TAI is defined as an incrementing second count, so it has no minute/hour/day units etc). Keean.

Ketil Malde

12:06 p.m.

New subject: System.Time.Clock Design Issues

"Bayley, Alistair" writes:

...

- UTC/POSIX/CalenderTime are isomorphic, and represent some idealised notion of time where leap seconds don't exist i.e. a day always has duration 23:59:59.

I don't think this is correct. In UTC, extra leap seconds are denoted 23:59:60 and the missing ones have :59:58 as the last second. Posix's seconds are thus not isomorphic to UTC.

...

- Most (all?) system clocks return UTC. They may slow down around leap seconds to support this - is this behaviour only seen on systems with NTP?

I think so.

...

- It's not possible to simply get the number of actual ticks since some epoch; the OS time function may slow down for leap seconds and we can't avoid this.

Unless you move the epoch, which is basically what POSIX does. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

Benjamin Franksen

6:24 p.m.

New subject: System.Time.Clock Design Issues

On Thursday 03 February 2005 16:14, Bayley, Alistair wrote:

...

- This means TAI time can only be calculated accurately when we have the full leap second table available.

What about making the leap seconds table (LST) a parameter of the UTC/TAI conversion? The LST could be some abstract type, readable via an IO action either from the System (if future systems support this) or from some file. The point in time up to which the table is garanteed to be accurate should be a (queryable) property of the LST. Ben

Peter Simons

6:45 p.m.

New subject: System.Time.Clock Design Issues

Benjamin Franksen writes:

...

What about making the leap seconds table (LST) a parameter of the UTC/TAI conversion?

That is definitely a good idea. If I didn't get it wrong, then any TAI to Calendar Time conversion needs this information to be accurate: * TAI time to convert, * TAI time when the above timestamp was created, * and the table of leap seconds in TAI. This is the only way a TAI timestamp into the future can be converted back to Calender Time accurately -- at all points in time. Or so I believe. Peter

Keean Schupke

7:05 p.m.

New subject: System.Time.Clock Design Issues

Peter Simons wrote:

...

Benjamin Franksen writes:

...
What about making the leap seconds table (LST) a parameter of the UTC/TAI conversion?

That is definitely a good idea. If I didn't get it wrong, then any TAI to Calendar Time conversion needs this information to be accurate:

* TAI time to convert, * TAI time when the above timestamp was created, * and the table of leap seconds in TAI.

This is the only way a TAI timestamp into the future can be converted back to Calender Time accurately -- at all points in time. Or so I believe.

If the system provided the current time as either UTC or TAI, would there be any application that would need to convert between the two? Keean.

Seth Kurtzberg

7:38 p.m.

New subject: System.Time.Clock Design Issues

I had a thought on the leap second issue. I noticed that on an NIST web site, you can obtain not only the leap seconds to date, but also the scheduled leap seconds for several years into the future. Using this table would almost project you from an out of date leap second table. This would eliminate the problem of the table becoming out of date, because future leap seconds would also be in the table. It's not a perfect solution, as in rare cases an additional leap second is added (one that does not appear on the schedule of future leap seconds). Even so, it is highly likely to be correct about future leap seconds, so the library is highly likely to be correct (w.r.t. leap seconds). Someone suggested applying the leap second table as an argument. If the scheduled leap second table is built into the system, that argument could, instead, identify any leap seconds that for some reason were not on the schedule. I'd be inclined to use the table, with past and scheduled leap seconds, and worry about modifications to the table later, since the odds are that such modifications won't occur. Keean Schupke wrote:

...

Peter Simons wrote:

...
Benjamin Franksen writes:

...
What about making the leap seconds table (LST) a parameter of the UTC/TAI conversion?

That is definitely a good idea. If I didn't get it wrong, then any TAI to Calendar Time conversion needs this information to be accurate:

* TAI time to convert, * TAI time when the above timestamp was created, * and the table of leap seconds in TAI.

This is the only way a TAI timestamp into the future can be converted back to Calender Time accurately -- at all points in time. Or so I believe.

If the system provided the current time as either UTC or TAI, would there be any application that would need to convert between the two?

Keean.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

!DSPAM:4202c11e28858748444101!

Ashley Yakeley

8:24 p.m.

New subject: System.Time.Clock Design Issues

In article <4202C3F5.8060902@cql.com>, Seth Kurtzberg wrote:

...

I noticed that on an NIST web site, you can obtain not only the leap seconds to date, but also the scheduled leap seconds for several years into the future.

Do you have a link for that? Leap seconds are only announced with six months' notice. -- Ashley Yakeley, Seattle WA

Seth Kurtzberg

8:45 p.m.

New subject: System.Time.Clock Design Issues

Ashley Yakeley wrote:

...

In article <4202C3F5.8060902@cql.com>, Seth Kurtzberg wrote:

...
I noticed that on an NIST web site, you can obtain not only the leap seconds to date, but also the scheduled leap seconds for several years into the future.

Do you have a link for that? Leap seconds are only announced with six months' notice.

I'll dig it up. On Iridium we programmed in the leap seconds for the useful life of the vehicle, which is about five years. It is guaranteed to be accurate, but in the case that we used it there was an extra leap second just before we launched, and none after that. Partly luck, of course.

Ashley Yakeley

9:02 p.m.

New subject: System.Time.Clock Design Issues

In article <4202D3B1.8060709@cql.com>, Seth Kurtzberg wrote:

...

I'll dig it up. On Iridium we programmed in the leap seconds for the useful life of the vehicle, which is about five years. It is guaranteed to be accurate, but in the case that we used it there was an extra leap second just before we launched, and none after that. Partly luck, of course.

I found this: http://www.boulder.nist.gov/timefreq/pubs/bulletin/leapsecond.htm It doesn't have any information about future leap seconds beyond the announcement that there wouldn't be one at the end of June 2005. In general I don't believe we get more than six months' notice of them. I daresay you were lucky with your project: they could have announced another leap second two or three years after your product was released. -- Ashley Yakeley, Seattle WA

Ashley Yakeley

8:48 p.m.

New subject: System.Time.Clock Design Issues

In article <200502040024.46434.benjamin.franksen@bessy.de>, Benjamin Franksen wrote:

...

What about making the leap seconds table (LST) a parameter of the UTC/TAI conversion? The LST could be some abstract type, readable via an IO action either from the System (if future systems support this) or from some file. The point in time up to which the table is garanteed to be accurate should be a (queryable) property of the LST.

This would certainly be the best way to provide any kind of TAI support, given that TAI time is difficult to obtain from the system. I can think of two possible types for the table. Bear in mind leap-seconds can be both insertions and removals, though so far they've all been insertions. type JulianDay = Integer; -- day number type LeapSecondTable1 = JulianDay -> Int -- TAI - UTC on given day type LeapSecondTable2 = [(JulianDay,Int)] -- list of leap-seconds utcDayLength :: LeapSecondTable1 -> JulianDay -> Int utcDayLength lst d = 86400 + (lst (d + 1)) - (lst d); I rather prefer LeapSecondTable1. Either way, we could provide the table known at compile-time, or rather at compiler release time, however useful or not that may be: knownLeapSecondTable :: LeapSecondTable knownLeapSecondTableLimit :: JulianDay bestGuessLeapSecondTable :: LeapSecondTable The difference is that knownLeapSecondTable has no leap seconds after knownLeapSecondTableLimit, while bestGuessLeapSecondTable puts some in to keep track of the likely long-term difference as best it can. Again, I don't know how useful that is if it's going to become out of date a year or two after compiler release. If we did this sort of thing, we might consider putting TAI and leap-second handling into a separate module. -- Ashley Yakeley, Seattle WA

7410

Age (days ago)

7411

Last active (days ago)

List overview

Download

10 comments

7 participants

participants (7)

Ashley Yakeley
Bayley, Alistair
Benjamin Franksen
Keean Schupke
Ketil Malde
Peter Simons
Seth Kurtzberg

RE: System.Time.Clock Design Issues

tags

participants (7)