[LEAPSECS] Automation

[M. Warner Losh]

In message: <151A3828-174F-41DB-917A-0C98C8430DCD at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:

: Tony Finch wrote:

: 

: > The lack of automation is a recipe for mistakes, but leap seconds  

: > can't be automated because they don't occur on a predictable schedule.

: 

: They can't be naively automated.  The schedule is currently  

: predictable 6 months in advance.


That's not much of a prediction.  No offense to the current Bulletin C
folks, but 6 months is way too short a time frame for proper
coordination.


: Nobody has objected to a longer  

: schedule; we're positively giddy to give it a try.  NTP is proof of  

: concept that automation is possible once the schedule is released.


Well, ntpd does require manual intervention at the head end to work.
Some reference clocks (stratum 1) do light the leap second indicator
automatically, but not all.


: Of course, the benefits of naive automation are precisely what the ITU  

: is trying to take away from UTC.  Leap seconds are the price of  

: preserving easy access to knowledge of Earth orientation.

: 

: Since the problem space has never been fully explored, we haven't even  

: speculated on ways to improve the automation associated with  

: timekeeping.


If we must have leapseconds, we must put them on a better schedule
than 'we'll tell you 6 months in advance'.

If one accepts > .9s tolerance, we can make our best guess now for the
next 10 years and be very likely to be very close.  We'd likely know
after 5 years how well we've done.  Having leap seconds on a
predictable schedule out many years would solve many of the
engineering problems that are faced today.

It still wouldn't solve the fact that POSIX time_t is fundamentally
incompatible with leap seconds.  It is incapable of expressing
23:59:60 unambiguously.  The obvious solution of running in 'TAI' time
breaks a lot of code because lots of code assumes it knows how to do
the math itself.  In addition, there's no difference between
2008-12-31 23:59:60 and 2009-01-01 00:00:00 when encoded in a struct
tm, due to the normalization rule.

Warner