[LEAPSECS] Leap seconds have a larger context than POSIX

[Tom Van Baak]

Warner,

 > Yes. I wish it were clearer that TAI time is a regular radio 
expression of time.
 > Here regular radix means that it every day has 24 hours and every 
hour 60 minutes
 > and every minute has 60 seconds.

I'm not sure it's fundamental to TAI that one must always, or only, use 
24x60x60 radix notation. That's a useful convention in many cases, but 
at the h/w counter or s/w binary integer level radix notation is not 
required.

The key features of that timescale are its rate, its epoch, its 
continuity, and its lack of physical, astronomical, or political 
interference. A side effect is that this is a timescale that can be 
converted to/from broken-down date/time format in perpetuity using 
simple math and without using external tables.


 > At the moment there are only two opportunities to consider, though the
 > standard allows up to end of every month.

Code should allow for a leap second event at the end of any month. The 
June / December thing is one of several guidelines for BIPM; it's not a 
rule that anyone writing UTC code should assume or depend on. Nor should 
code ever assume leap seconds are positive.

 > This ambiguity has lead to bugs when leaps were announced more than 3 
months
 > in advance. I'd feel better if there were a commitment to these 
parameters for some
 > number of years. But it's all just convention today.

There's no ambiguity. Those are just bugs. No software should depend on 
more than 1 month notice of a leap second and no software should be 
fooled if the notice is months or even years in advance.


 > Have I forgotten any of the other details of leap seconds that are more
 > tribal knowledge than rigorously specified?

If you're writing a FAQ or best practices guide stay in touch. I have a 
semi-technical leap second report in the works. UTC is actually very 
simple; but it's been complicated by untold levels of bad assumptions, 
bad execution, and bad prose.

/tvb

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20200205/9481f7c3/attachment-0001.html>