In message <E1E0ysB-0003IZ-00_at_mta1.cl.cam.ac.uk>, Markus Kuhn writes:
>Example: We both schedule an event on 2006 January 2005 00:00:00 UTC. If
>I convert this schedule from UTC to my system-internal TAI before the
>announcement of the next leapsecond at the end of this year, but you
>convert it after you receive this announcement, then we both will
>schedule this event 1 second apart, even though we thought we had an
>unambiguous agreement.
This is actually just one example of a much greater class of problems,
with clocks not being rigid.
Most systems do not hang around in their bootstrap to make sure they
know what time it is before proceeding (people have no patience for
that sort of correctness any more) so it is not uncommon for the
UTC clock to take a step at some pointer after boot.
Remote systems which only synchronize clocks once per day may also
have multi second steps.
If a program, take named as random example, has scheduled a check
on a DNS zone 200 seconds from now, and the clock is subsequently
stepped, then the event may never happen, may happen too soon
or happen too late if the event is scheduled on the UTC timescale.
Now, named is very tolerant application, even if the users are
not, so this is not as fatal as it could be, but there are plenty
of more critical applications.
Therefore, all programs which need to schedule events in relative
time should not use the UTC timescale, but rather the "CLOCK_MONOTONIC"
timescale from clock_gettime, because they are guaranteed that
timescale is not stepped.
On the other hand, if an event is sceduled with second precision
in real time on the UTC scale, the program should _not_ rely on
predictability for more than some few hours on the regular kind of
computer hardware, and therefore a traditional strategy is:
while (not happened)
calculate delta-T
if (delta-T > 2day)
sleep 1 day
else if (delta-T > 2 hours)
sleep 1 hour
else if (delta-T > 2 minutes)
sleep 1 minute
if (delta-T > 0
sleep 1 second
Binary search can also be used:
while (not happened)
calculate delta-T
sleep (delta-T / 2);
But is a lot less resistant to typical human errors in system
operation.
>For >99% of all applications, using TAI as the time_t basis is the wrong
>trade-off today in distributed computing.
If we knew the timing of all leapseconds in the next 50 years at
any one time, it wouldn't be a problem.
>In addition, it is against
>what the POSIX standard says, which sees time_t as an integer-encoding
>of a UTC clock value rather than as a simple count of seconds (although
>the historic term unfortunately "Seconds since the epoch" suggests
>otherwise to anyone who hasn't actually read its exact definition).
I've come to the conclusion that while POSIX is a good thing, we shouldn't
let it get in the way of a correct solution.
I've never been able to nail down who made this particular POSIX_MISTAKE
btw, a post-factum interview could be interesting :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Received on Fri Aug 05 2005 - 03:10:32 PDT