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- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/faq.html