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
_______________________________________________
LEAPSECS mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/leapsecs
