[LEAPSECS] internet drafts about zoneinfo (POSIX Time)

[Warner Losh]

>

>> I've described it to coworkers as "time_t is one second per SI second,

>> steady state."  Leap seconds perturb this steady-state in any number of

>> implemetnation dependent ways:

>>

>> (1) Time stops for a second.

>> (2) The last second of the day repeats

>> (3) The first second of the day repeats

>> (4) Time slews from N seconds before midnight to N seconds after midnight

>> (5) Nothing happens, until NTP notices the phase error and steers it out

>> (6) Nothing happens, and time is wrong.

>>

>> But I'm not sure how much of this is actually mandated by the standard,

>> and how much is reading between the lines. :)

>>

>> Since the standard doesn't define what happens around leap seconds, all

>> of the above behaviors are conformant.

> I think (7) is probably the most common:

>

> (7) Time was wrong (by at least a few seconds) before the leap second,

>      and time is wrong after the leap second.    (In this case, leap

>      seconds matter not at all.)

>

> I cannot think of a situation where civil time accuracy needs to be

> any better than +/- one second.  That is why leap seconds are OK and

> not a problem in most all cases, even if there are computers around

> that are trying to follow the posix spec.


Because you can't think of it doesn't mean it doesn't exist.  There are 
many situations where you need better than sub-second accuracy for the 
processes that are being controlled.  From manufacturing where time 
stamps must be accurate to a second and traceable to NIST, to high speed 
trading where you're trying to time the absolute top of the market and 
know that will happen soon.


> If NTP is there and (5) happens, what problem could there possibly be?


Usually, there are no problems.  However, there can be problems in those 
cases where computers are talking to each other and have to agree to 
coordinate some action.

Again, just because there usually aren't problems, doesn't mean there 
aren't any problems at all.  We've seen a growing trend for things to be 
faster.  As they get faster and faster, these issues will continue to 
come up in increasing frequency.


> If you're doing something technical where precise interval time

> measurements need to remain accurate (even over leap second events),

> then you need to understand your system better than a POSIX spec could

> possibly inform you, and I don't think neglecting to maintain UTC (by

> neglecting to insert leap seconds as needed to keep it within +/- one

> second of the correct time) would change that.

>

>


The problem with that attitude is that systems with that attitude become 
impossible to implement precice time on.  It is injecting policy (we 
don't care about time) into a system that should just provide tools 
(here's the tools to do leap seconds right, but if you don't use them 
then we fail safe).

Warner