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

469Re: [ISO8601] Leap seconds

Expand Messages
  • Tex Texin
    Jul 1, 2002
    • 0 Attachment
      The problem for software is the unpredictability of when leap seconds
      will be added.
      If they were added at predictable times, then software could easily
      accomodate them.
      We need to add one about every year and a half. I wonder if it wouldn't
      be better to schedule them out a hundred years so most software could
      take them into account and let the astronomical software that needs
      accuracy greater than 1 second deal with the special cases of where
      astronomical time is different from utc.

      Today, if I want to validate time that a user enters, I cannot know
      whether to reject a minute with 61 seconds or not because it might
      potentially have had a leap second added.

      tex

      Ed Davies wrote:
      >
      > 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
      >
      > Yahoo! Groups Sponsor
      > ADVERTISEMENT
      > [Click Here!]
      >
      > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

      --
      -------------------------------------------------------------
      Tex Texin cell: +1 781 789 1898 mailto:Tex@...
      Xen Master http://www.i18nGuy.com

      XenCraft http://www.XenCraft.com
      Making e-Business Work Around the World
      -------------------------------------------------------------
    • Show all 2 messages in this topic