[LEAPSECS] Prospective Leap Seconds

[Ian Batten]

One of the arguments advanced as to why leap seconds are bad is that  
it's difficult to know when they are due.  Broadcast standards don't  
provide much notice, there are systems that need to know (or are felt  
to need to know) a reasonable proxy for UT1 yet don't have access to  
the Internet or other non-broadcast standards, and therefore leap  
seconds complicate matters substantially.   Those systems may have a  
bumpy ride through a leap second, but the rest of the time they do at  
least have access to UT.   But that's at the price of systems that  
really only need a monotonically increasing time having the bumpy ride  
during leap seconds, but getting no advantage from that time being UT  
rather than TAI+constant.

Roughly the same argument causes problems if UTC is fixed as TAI 
+constant: systems that need to concern themselves with positioning  
need to get access to "new UTC''s offset from UT1, and if it's not in  
broadcast standards and they don't have access to t'Internet, what to  
do?  Systems that don't need positioning get their monotonic clock, at  
the expense of people who need UT losing.

But the main argument I've heard for the problems with leap seconds is  
that for Posix-based, or any "seconds since epoch disciplined by  
broadcast clocks" computers, leap seconds leave no trace in long-term  
interval timing and therefore make a mess of time arithmetic as well  
as of time-stamps around midnight on the critical days.  A lot of that  
is soluble in retrospect: a 12 monthly update will provide a complete  
list of past leapseconds, and missing that update for a few years only  
introduces errors of a second or so.  So that's retrospective  
leapseconds pretty much solved.  But if an application needs access to  
prospective leapseconds, or, alternatively, to prospective DUT1 (be  
that bounded to 0.9s or not) then that's not available prospectively:  
you either have access to it in near-real-time, or you lose.

How many applications are there that (a) need access to UT and (b)  
operate without access to t'Internet or other means of disseminating  
an extended DUT1?

I ask, because I think there are two problems being conflated:

1.  The cost of change for existing kit; and

2.  The long term sustainability of _any_ kit.

So there may be an instance of an application which only has access to  
broadcast standards and needs DUT1.  Fixing that, even if you can wave  
a magic wand and change the client, requires changes to the broadcast  
if DUT1 is allowed to increase beyond 0.9s.  On the other hand, if  
there were a decision to release the constraint on DUT1 in, say, 20  
years' time, then the amount of kit affected is small unless it falls  
into this category.

ian