Loading ...
Sorry, an error occurred while loading the content.

Re: [ISO8601] predictability of leap seconds

Expand Messages
  • Ed Davies
    ... I agree - my comments below are an expansion of this point. ... That s the spirit... :-) ... This averaging out is a key point. As I understand it - the
    Message 1 of 2 , Jul 3, 2002
    • 0 Attachment
      Tex Texin wrote:
      > Fred,
      > Possibly. Sometimes the solutions you get are a function of the
      > requirements you choose to satisfy.
      > So Perhaps.


      > 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
      > predictability.

      I agree - my comments below are an expansion of this point.

      > I am not an expert on the subject and will not pretend to be. (But I'll
      > press on anyway! ;-) )

      That's the spirit... :-)

      > 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.

      This averaging out is a key point. As I understand it - the
      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 allowed
      > to have minutes with 61 seconds will be held in check. (Although
      > realistically neither problem is that big a deal.)

      I don't think the concerns are so much with respect to user
      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
      time base.

      > Actually, I would settle for a 10 year plan, since most software has a
      > lifespan or at least an update cycle, less than that.

      As long as time convertions and arithmetic are done by the OS or a
      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.

      > ...
      > (Please don't someone reply that web services will fix all of this
      > anyway. ;-) )

      Well, having the IERS bulletins available in a convenient format
      (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.

    Your message has been successfully submitted and would be delivered to recipients shortly.