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

468Leap seconds

Expand Messages
  • Ed Davies
    Jul 1, 2002
    • 0 Attachment
      Following is a reply I am posting to a list regarding satellite
      observation which might be of interest to ISO 8601ers. I'm a
      bit surprised the subject hasn't been mentioned here before.

      --------------------------------------------------------------------------
      jcm@... wrote:
      >
      > This is a hot topic right now: the GPS community (at least I think
      > they are the perpetrators) are trying to persuade IERS to abandon leap
      > seconds entirely so that their software is easier.

      My first thought was that the idea of dropping leap seconds was
      potty but having read a bit about it and reflected on the requirements
      and knowledge of different users I'm coming round to the view that
      it might not be such a bad idea.

      A Google search for "UTC" and "redefinition" showed up a good discussion
      of who's behind this and why at:

      http://space.mit.edu/URSI/leapsecond.html

      particularly:

      http://space.mit.edu/URSI/lsappendix3.html

      As often happens with picky subjects like this, Markus Kuhn is a fount
      of knowledge, see the references at the end of his <time.h> article:

      http://www.cl.cam.ac.uk/~mgk25/c-time/

      paticularly:

      http://www.cl.cam.ac.uk/~mgk25/c-time/metrologia-leapsecond.pdf

      for a very detailed discussion of the history of leap seconds and
      a reasonable discussion of why they should be dumped.

      It doesn't seem to be the "GPS community" as such who want this change
      but rather the many people who want to synchronise computer networks to
      better precision than a few seconds but with software which doesn't
      spend all its time worrying about either leap seconds or the difference
      between civil time (as typed in by the user/operator setting the
      clock) and TAI.

      > This would mean
      > noticeable drifts of UTC relative to the sky on timescales of a decade
      > or so, and make a lot of professional astronomy software seriously
      > broken.

      In most cases, only if it assumed that UT1 - UTC < 1 second (as it
      appears that the format of some timesignals do) or that UT1 and UTC
      are close enough not to matter. There are no leap seconds due for
      a while so there'll be plenty of time to fix this.

      > The astronomy community are screaming and telling the nav
      > people that if they don't like leap seconds they should just use
      > a perfectly good preexisting timescale like TAI or TT, and don'tmess
      > with our UTC.

      I guess the question is: should the operation of UTC be determined
      by the needs of the astronomers who understand things like the
      difference between UT1 and UTC or by the needs of the rest of the
      world who hardly care at all?

      On the other hand - as computers get more connected (e.g., more
      "always on" connections) protocols like NTP will be used more and
      more to set and correct the computer clock so getting leap second,
      (UTC - TAI) and even (UT1 - UTC) information will be automatic and
      not bother the user anyway.

      > Today is actually the deadline for users of UTC to
      > send in their comments on the proposal: see the questionnaire at
      > http://hpiers.obspm.fr/eop-pc/products/questionnaire-utc.txt
      > and if you have strong opinions about leap seconds, send it in TODAY.
      > Would visual observers prefer to switch to something like TAI?

      I think observers should continue to use UTC as it relates so
      directly to civil time. Analysts and prediction software should
      ideally take leap seconds into account. A good way would be to
      use TAI consistently internally - that is, subtract the appropriate
      UTC - TAI from received observations or elements and add back the new
      appropriate offset to predictions or predicted elements.

      This would mean that predications for a pass on January 1st after
      a leap second at the end of the previous year would be correctly
      calculated from observations taken over the previous few days -
      whether or not the epoch of the elements used was before or after
      the midnight at the start of that day.

      Dropping leap seconds from UTC would eliminate the need for this
      nonsense.

      > Or do you like the fact that UTC directly relates hour angle to
      > RA (admittedly only at equinox of date?). It'll be thousands of years
      > before we start getting daylight at midnight due to lack of leap
      > seconds, so it won't bother the average member of the public.
      > - Jonathan McDowell
    • Show all 2 messages in this topic