Re: Introduction of long term scheduling
So you think it is appropriate to demand that ever computer with a clock should suffer biannual software upgrades if it is not connected to a network where it can get NTP or similar service ? I know people who will disagree with you: Air traffic control Train control Hospitals and the list goes on. FWIW, I believe most hospitals are more than capable of looking after equipment with complex maintenance schedules. They have endoscopes, blood gas analysers, gamma cameras, MRI machines, dialysis machines and a rake of other stuff that has a schedule requiring attention more regurally than once every 6 months. I am not sure how much un-networked equipment that requires UTC to 1 second and doesn't already have a suitable maintenance schedule exists in hospitals. David.
Re: building consensus
I belive this was because the year followed the taxation cycle of the government whereas the day+month followed the religiously inherited tradtion. Indeed. For that matter, the start of the U.K. tax year was left alone when the calendar changed, and is now 6 April (it should be 7 April, but for whatever reason no adjustment for 1900 was made). Unsurprisingly, Ireland originally followed the UK tax year. However, in 2000 the tax year ran from April 6 until December 31. Since then our tax year is in sync with the calendar year. (I guess this is a recent example of calendar reform that went relatively smoothly.) David.
Re: building consensus
Quintilis was renamed after Julius Caesar. Later Sextilis was renamed after Augustus Caesar. It is often said that the month lengths were changed at the same time, but at least one version of that story is fabricated and there's a distinct lack of evidence for it. Other emperors had months renamed after themselves too, but those names didn't stick. There's no evidence that any of them was accompanied by changes in the lengths of months either. The Oxford Companion to the Year is pretty explicit about this in its chapter on the Roman Calendar. It says that before Julius Caesar: Ianuarius29 Quinctilis 31 Februarius 28 Sextis 29 Martius 31 September29 Aprilis 29 October 31 Maius31 November 29 Iunius 29 December 29 The reason was most of the months had odd lengths because odd numbers were lucky, but to get the year to have an odd number of days you need one month to have an even number of days. There was a leap month system where Februarius was cut short and an extra month was inserted. After the reform: Ianuarius31 Quinctilis 31 Februarius 28 Sextis 31 Martius 31 September30 Aprilis 30 October 31 Maius31 November 30 Iunius 30 December 31 They also explain where the extra days were inserted. They say Quinctilis was renamed Julius after he'd been murdered. Their entry for 30 February notes: There is no truth in the assertion by some modern (but no ancient) writers that Julius Caesar gave all the odd months 31 days, February 29 days and 30 in a leap year, and all the even months (including Oct) 30, but that Augustus upsets the logical arangement in order to make his month of August as long as Caesar's July. Nevertheless, 30 February has existed three times in the calendars of particular countries: once in Sweden, twice in the Soviet Union. David.
Re: Risks of change to UTC
Professional and amateur astronomers are not the only ones who need good estimates of UT1. I've been wondering about this for a bit. Do astronomers and navigators actually want UT1 or do they want GMST? Since UT1 is based on a mean sun, which I guess no one actually observs, it would seem that GMST would be much more useful for figuring out your position or observing something. As far as I can see from my 1992 edition of the Explanatory Supplement to the Astronomical Almanac, UT1 and GMST were (defined?) to be related to one another by a cubic (2.24-1): GMST1 of 0hUT1 = 24110.54841s + 8640184.812877s T + 0.093104s T^2 + 0.062s T^3 What I don't know is: are the coefficients of this equation constant, or periodically updated by the IAU? Do astronomers, navigators and almanacs have to update their calculations when/if the IAU make a change? Why do I think they may change? Well, In older explanatory supplements to the IERS bulletins, such as this one: http://igscb.jpl.nasa.gov/mail/igsmail/1999/msg00077.html they give a reference for the relationship used as a paper by Aoki et al., 1982. However, in this more recent explanatory supplement: http://hpiers.obspm.fr/eoppc/bul/bulb/explanatory.html the relationship seems to have been changed to ones documented in (Capitaine et al., 2000, Capitaine et al., 2003, McCarthy and Petit, 2004). They say that that This relationship was developed to maintain consistency with the previous defining relationship, but I think this probably means that they were stitched together in a smooth way, not that they are identical. If it is the case that the GMST/UT1 relationship is changed regularly and astronomers/navigators have to keep up with those changes, then leap seconds could be put into this relationship (amounting to moving the mean sun when needed). I'm guessing that this suggestion is only slightly less crazy than strapping rockets onto the Earth to speed up its rotation ;-) David.
Re: The real problem with leap seconds
Yes: there is an order on the set of values of timescales - it is a basic property of spacetime models that one can distinguish past and present, at least locally. Spacetime is a differentiable 4-dimensional manifold, its coordinate functions are usually two times differentiable or more. In particular, the set of values of timescales does indeed have a topology (which is Hausdorff). Sure - this is a reasonable definition of timescale, but I don't think it is wide enough to include UTC. As I understand it, and everyone will correct me if I'm wrong, UTC is not intended to be directly related to spacetime coordinates at all. UTC is (currently) an aproximation to the direction the earth is facing and is adjusted according to how long it takes the earth to end up facing the same direction again. All of this is completely independent from the choice of a particular calendar or of the time units to be used for expressing timescale values. I'd agree with this for TAI (including that it should be the integral of a nice 1-form), but I'm not so sure for UTC. If you subtract a time from a timescale value, you get another timescale value. If you mean to say that UTC takes its values in a different space than TAI then you cannot agree with UTC = TAI - DTAI, as in the official definition of UTC. And if you say that UTC - TAI can be discontinuous (as a function of whatever) with both UTC and TAI continuous then you must have a subtraction that is not continuous. Strange indeed. Where did I misinterpret your post? Yep - you've picked up my intent correctly. I'm saying that subtraction is a stange operator taking a UTC value and a TAI value and gives you something that's a real number. The reason that I came to this conclusion is because none of the documents I've read say that UTC can be expressed as a real number - they all suggest it is expressed as labelled seconds. (For example, see the way that Rec. 460-4 gives UTC values - I've never seen an official looking document that tries to write UTC as a real.) David.
Re: The real problem with leap seconds
[A lot of discussion on this list seem to revolve around people understanding terms in different ways. In an impractical example of that spirit...] I do not understand. As a function of TAI, UTC is neither continuous nor monotone increasing in the mathematical sense. To say if TAI is a monotone function of UTC, you need to put an order on the set of possible TAI and UTC values. To say if UTC is a continious function of TAI, you need to put a topology on both. To me, TAI seems to be a union of copies of [0,1) labelled by YEAR-MM-DD HH:MM:SS where you glue the ends together in the obvious way and SS runs from 00-59. You then put the obvious order on it that makes it look like the real numbers. OTOH, UTC seems to be a union of copies of [0,1) labelled by YEAR-MM-DD HH:MM:SS where SS runs from 00-60. You glue both the end of second 59 and 60 to the start of the next minute, in adition to the obvious glueing. I haven't checked all the details, but seems to me that you can put a reasonable topology and order on the set of UTC values that will make UTC a continious monotone function of TAI. The topology is unlikely to be Hausdorf, but you can't have everything. DTAI jumped from 32 s to 33 s; thus, UTC is not a monotone increasing function of TAI either. Since DTAI involves subtracting quantities that aren't real numbers, you can't conclude that a discontinuity in DTAI results in a discontinuity in UTC. David.
Re: NTP behavior in Australia
I grabbed a set if IP#'s from pool.ntp.org and monitored them in the 24 hours before and 8 hours after the leap. I did something similar using the public NTP server lists on the ntp wiki. I'm still collecting the data, but I have some plots of what's happening with the leap bits at: http://www.maths.tcd.ie/~dwmalone/time/leap2005.html It wasn't really until 24 hours before that a significant number of servers were advertising the leap, peaking in the last measurement before the leap. Interestingly, one server actually advertised a leap in the wrong direction! After the leap it looks like more stratum 1 servers were unsynchronised than usual, though that seems to have setteled down a bit now. The number of people with the leap bits set is dropping, but isn't quite zero yet. I have the peers information from out local ntp server around the leap. Our server did the right thing, but it looks like there were a number of others that didn't. I haven't figured out how to visualise that yet. David.
