Ulrich Windl wrote:
> The time in the kernel is seconds since the epoch. To insert a second
> means that we'll have to delay the next second for another second.
> The other solution seems to be a clib -> kernel interface that knows
> that a leap second is active now. Then the clib could possibly
> convert the seconds to xx:yy:60. (I hope I did not overlook something
> obvious).
And Andrej Presern replied:
>> Have you considered simply not scheduling any processes for one second and
>> adjusting the time accordingly? (if one second chunk is too big, you can do
>> it in several steps)
The problem is that POSIX is schizophrenic on the subject of leap seconds.
On the one hand, time() returns UTC time. On the other,
t = time();
sec = t % 60;
t /= 60;
min = t % 60;
t /= 60;
hr = t % 24;
t /= 24;
printf("UTC time is %lu days, %02u:%02u:%02u\n", (unsigned long)t, gr, min, sec);
is required to work (since so much code does it.)
Actually, I think Ulrich was present when I proposed a similar solution:
gettimeofday() will not return during 23:59:60. If a process calls
gettimeofday() during a leap second, then the call will sleep until 0:00:00
when it can return the correct result.
This horrified the real-time people. It is, however, strictly speaking,
completely correct.
The real-world solution (a.k.a kludge), is to stretch some number of
seconds to cover the n+1 seconds including the leap second. During
those seconds, gettimeofday() is incorrect, but the error is
well-defined, so two "good" implementations will return "close" values
and you can undo the fudging afterwards if desired.
The only trick is to define the number of seconds n, their position
relative to the leap second, and they type of stretching. Linear is
obvious, making the 60 seconds leading up to a leap second take 61/60
of the usual time, but you could define a polynomial with higher-order
continuity.
--
-Colin
Date: Tue, 8 Sep 1998 22:46:25 -0600 (MDT)
From: Colin Plumb <[email protected]>
The problem is that POSIX is schizophrenic on the subject of leap seconds.
On the one hand, time() returns UTC time.
Yep. See POSIX 4.5.1.2, 2.2.2.77, 2.2.2.24, and the rationale for
Epoch, found in B.2.2.2).
On the other,
t = time();
sec = t % 60;
t /= 60;
min = t % 60;
t /= 60;
hr = t % 24;
t /= 24;
printf("UTC time is %lu days, %02u:%02u:%02u\n", (unsigned long)t, gr, min, sec);
is required to work (since so much code does it.)
In fact, POSIX requires this (see 2.2.2.77).
Actually, I think Ulrich was present when I proposed a similar solution:
gettimeofday() will not return during 23:59:60. If a process calls
gettimeofday() during a leap second, then the call will sleep until 0:00:00
when it can return the correct result.
The other possibility is for gettimeofday() to return the same value for
23:59:60 and 00:00:00. This would also strictly speaking be correct.
time() is specified as returning "seconds since the Epoch", which is
defined as:
tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
(tm_year-70)*31536000 + ((tm_year-64)/4*86400)
where tm_sec, tm_min, tm_hour, etc. together form a Curridnated
Universal Time name.
Hence, the above equation would have the same value for 23:59:60 and
00:00:00 on the next day. Hence, time() should return the same value.
- Ted