Marcin 'Qrczak' Kowalczyk wrote:

Keean Schupke writes:

...

Yes timing between point in time should be independant of leap seconds, so if a program, takes 5 seconds to run it should always take 5 seconds, even if it runs accross midnight.

How would you implement it, given that gettimeofday() and other Unix calls which return the current time either gradually slow down near a leap second (if NTP is used to synchronize clocks) or the clock is not adjusted at all, and at the next time it is set it will just be on average one second later (if it is being set manually)?

The computers timer should not attempt to adjust for leap seconds... Consider it a chronograph. Keean.

Peter Simons writes:

...

The computers timer should not attempt to adjust for leap seconds...

I seem to recall reading somewhere that leap second inserts are supposed to be represented as:

23:59:59 23:59:60 00:00:00

Yes, but Unix API doesn't use this. The OS communicates in terms of UTC seconds since the epoch (and microseconds / nanoseconds). Userspace translates between this and broken-down time (year, month etc.), and UTC doesn't have leap seconds. Userspace also takes timezones into account - the kernel reports UTC only. I don't know how it looks on other systems. On Linux it is possible to set timezones which assume that the system time is TAI instead of UTC, and translate it to UTC. In this case the local time can have tm_sec == 60. It breaks programs which rely on POSIX rules and perform the conversion themselves. I don't know how NTP clients handle this, and how many people actually use it in practice (it's not a default). -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

Keean Schupke writes:

...

How would you implement it, given that gettimeofday() and other Unix calls which return the current time either gradually slow down near a leap second (if NTP is used to synchronize clocks) or the clock is not adjusted at all, and at the next time it is set it will just be on average one second later (if it is being set manually)?

The computers timer should not attempt to adjust for leap seconds...

But it does. Eventually, or sometimes immediately (I don't know how fast NTP clients react, or whether they are programmed for faster adjustment around a leap second). All syscalls give us an approximation of UTC or a time derived from UTC. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

Keean Schupke writes:

If you don't run ntp (or you machine is not attached to the network) the timer will count milliseconds without adjustment for leap-seconds. When the machine is switched off, the hardware clock likewise does not account for leap-seconds. When you switch on time is copied from the hardware clock. The system timer (which counts time since switch on) will not be adjusted for leap-seconds surely, as its perpose is to measure a time interval.

It doesn't imply that it runs in TAI. I would guess it usually runs UTC using the previous leap second count (assuming it was accurate to a second at all), until someone sets it again. Well, I think PC clocks are not very precise at all if they are not synchronized with external sources. Linux NTP client has the feature of measuring and then adjusting the relative speed of the system clock for a reason. If some people run their system clocks in TAI, how should a Haskell system detect whether it's TAI or UTC? -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

Marcin 'Qrczak' Kowalczyk writes:

...

Yes timing between point in time should be independant of leap seconds, so if a program, takes 5 seconds to run it should always take 5 seconds, even if it runs accross midnight.

How would you implement it, given that gettimeofday() and other Unix calls which return the current time either gradually slow down near a leap second (if NTP is used to synchronize clocks) or the clock is not adjusted at all, and at the next time it is set it will just be on average one second later (if it is being set manually)?

So, the choice is either UTC, which corresponds to what most Unix (and other?) computers provide, but will generally be inaccurate in the presence of leap seconds. Or we can use TAI, which will in most cases have to be converted from UTC, and thus inherit all its inaccuracies in spite of its theoretically nice properties. At least with TAI it seems like if it would be possible to configure a system to do the right thing, so I would still vote for that (and as for Posix compatibility, well, it sucks in so many other ways anyway :-) (GPS doesn't use leap seconds either, btw) -kzm -- If I haven't seen further, it is by standing in the footprints of giants

On Thu, Jan 27, 2005 at 09:00:33AM +0100, Ketil Malde wrote:

Marcin 'Qrczak' Kowalczyk writes:

...

...

Yes timing between point in time should be independant of leap seconds, so if a program, takes 5 seconds to run it should always take 5 seconds, even if it runs accross midnight.

...

How would you implement it, given that gettimeofday() and other Unix calls which return the current time either gradually slow down near a leap second (if NTP is used to synchronize clocks) or the clock is not adjusted at all, and at the next time it is set it will just be on average one second later (if it is being set manually)?

So, the choice is either UTC, which corresponds to what most Unix (and other?) computers provide, but will generally be inaccurate in the presence of leap seconds. Or we can use TAI, which will in most cases have to be converted from UTC, and thus inherit all its inaccuracies in spite of its theoretically nice properties.

At least with TAI it seems like if it would be possible to configure a system to do the right thing, so I would still vote for that (and as for Posix compatibility, well, it sucks in so many other ways anyway :-)

It doesn't actually matter that much if we convert from UTC; presumably we have up-to-date leap second tables for the times in the past. (or mostly up to date) This means we can perfectly translate between the UTC clock in your computer and TAI to get the current TAI time. (and back and forth). there are only issues when using future UTC dates, but that is inherently problematic and at least we have TAI as an option which puts us ahead of a lot of other languages :) John -- John Meacham - ⑆repetae.net⑆john⑈