jcm@head-cfa.harvard.edu 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 ----------------------------------------------------------------- Unsubscribe from SeeSat-L by sending a message with 'unsubscribe' in the SUBJECT to SeeSat-L-request@lists.satellite.eu.org http://www.satellite.eu.org/seesat/seesatindex.html
This archive was generated by hypermail 2b29 : Mon Jul 01 2002 - 14:14:50 EDT