Re: [ISO8601] predictability of leap seconds
- Tex Texin wrote:
> Possibly. Sometimes the solutions you get are a function of the
> requirements you choose to satisfy.
> So Perhaps.
>I agree - my comments below are an expansion of this point.
> Or perhaps the designers of the system are focused on the needs of those
> (few?) that need that level of accuracy and not on the (large number of)
> software programs that need predictability and so designed in more
> precision than is needed (by most) at the cost of less than 6 months of
>That's the spirit... :-)
> I am not an expert on the subject and will not pretend to be. (But I'll
> press on anyway! ;-) )
>This averaging out is a key point. As I understand it - the
> We do know that we need to make an adjustment every year and a half or
> so. From 1972 to '99, there were 22 seconds added in the 27 year span.
> So I wonder if we couldn't plan to add another 20 or so in the next
> quarter century and then have a reckoning then. Over the course of the
> 25 years we might get a little more out of balance than 1 second but it
> would average out over time.
variation in the Earth's rotation consists of a fairly predictable
long term trend with shorter term (year to decade duration)
fluctuations on top. Recently the short term fluctations have,
presumably, tended to cancel out the long term trend so we've not
had any leap seconds for a while.
If the |UT1 - UTC| < 0.9s constraint were to be relaxed somewhat
(I leave it to the experts to work out by how much) then presumably
we could schedule leap seconds a much longer way out to take account
of just the long term trend.
> Meanwhile the number of users being allowedI don't think the concerns are so much with respect to user
> to have minutes with 61 seconds will be held in check. (Although
> realistically neither problem is that big a deal.)
interface issues such as this. They're more to do with systems,
particularly those in networks, not working out time differences
properly. E.g., two machines are synchronised and sending time-
stamped messages to one another. One implements leap seconds
properly and counts 23:59:59, 23:59:60, 00:00:00 while the other
counts 23:59:59, 00:00:00, 00:00:01. Suddenly one receives
timestamps from the "future".
Bearing in mind that national banks managed to get their ATM
machines not to work properly on February 29th not all that
many years ago, what are the hopes that relatively subtle
problems with unpredicatable and not so well known leap
seconds will be avoided.
E.g., GLONASS, the Russian sat nav system equivalent to GPS
needs to drop out for a short while to reset its clocks every
leap second as it uses UTC, unlike GPS which uses its own
>As long as time convertions and arithmetic are done by the OS or a
> Actually, I would settle for a 10 year plan, since most software has a
> lifespan or at least an update cycle, less than that.
suitable shared library it would be fairly easy for this to be
updated as required. None of the operating systems I run are older
than 10 years but quite a few little programs are. If lots of
software distributions (OS and application program) installed the
latest version of the "time library" (being careful not to overwrite
more recent versions of course) then the problem would go away.
> ...Well, having the IERS bulletins available in a convenient format
> (Please don't someone reply that web services will fix all of this
> anyway. ;-) )
(e.g., one based on XML) at a well known address might help - e.g.,
so that the "time library" mentioned above could update itself
every month or so.