Re: building consensus
On Mon 2006/06/05 22:04:40 -0400, John Cowan wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL All your points are correct, but it doesn't change the fact that there was no 1845-12-31 in Manila, any more than there was a second labeled 2006-04-02T00:02:30 in New York. There were two such, one labelled EST and the other EDT, neither were official but either could still be used without ambiguity. At the other end of the season there will be two and both will be official. C.f. email from me dated 2006/01/13 on this subject. Mark Calabretta
Re: building consensus
On Mon 2006/06/05 11:07:00 MST, Rob Seaman wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL Julian, just as the Julian succeeded what came before. That Caesar was more successful than Pope Gregory at convincing the world to rapidly adopt the new standard is a result of some pretty interesting historical differences between the two eras. The fundamental fact, ... but Pope Gregory was trying to do something harder - effectively to make the Gregorian calendar retrospective (proleptic) so that Easter would fall at the right time of year, and this required a calendrical jump of 11 days. A simple transition from the Julian leap year rule to the Gregorian rule (i.e. without calendrical discontinuity) would probably have been more saleable, especially to people with no interest in Easter. Mark Calabretta ATNF
Re: building consensus
On Mon 2006/06/05 22:04:40 -0400, John Cowan wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL there was no 1845-12-31 in Manila, any more than there was a As magic tricks go I don't find this one very convincing - I can clearly see the rabbits behind your back. Mark Calabretta ATNF
Re: Risks of change to UTC
On Sat 2006/01/21 10:11:04 PDT, M. Warner Losh wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL You really should read the archives of this list. We've been over this in great detail. TAI is specifically contraindicated as a time I don't think new contributors (or even old ones) should have to read the mountain of email, with its many irrelevant diversions, that has accumulated over the last 6 years - somewhat over 9MB by my count. Instead, I (re-)suggest that you (someone) write a position paper, or at least a FAQ, summarising your points. Mark Calabretta ATNF
Re: Risks of change to UTC
On Sat 2006/01/21 15:15:32 PDT, M. Warner Losh wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL Somewhere around betwee 45,000-80,000 you'll need more than one leap second a day. You should recognize this as a reductio ad absurdum argument; at that time there will be 86401 SI seconds per day - the absurdity being in continuing to pretend that there are only 86400. If at that time the number of seconds per day is officially changed to 86401 then the millenia of accumulated quadratic drift will be wiped away at once and the rate of accumulation of leap seconds reset to zero. The next step is to ask - what if we increased the official length of the day before the situation gets so far out of hand, to 86400 plus some fraction of a second? Mark Calabretta ATNF
Re: Monsters from the id
On Mon 2006/01/16 00:40:28 CDT, John Cowan wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL I realize the ALHP has severe problems with this, but I don't approve of the ALHP anyhow (save perhaps tactically, as explained). Agreement! But does anyone think that the leap hour proposal is anything other than a political device? If so, please describe in detail how it could/would work. Mark Calabretta ATNF
Re: The real problem with leap seconds
On Mon 2006/01/16 12:11:04 -, Michael Deckers wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL UTC (since 1972) is a disseminated timescale that is equal to TAI except for additional date and time codes transmitted with the signal. These codes indicate the values of TAI - DTAI for each full minute of TAI - DTAI. In a reading of UTC, (the most recent values of) these date and time codes can be taken as is so as to yield a reading that approximates UT1. The codes may also be used to derive the value of DTAI (from a table of leap seconds since 1972), and thus, to yield a reading of TAI. When a timestamp is characterised as UTC (rather than TAI), then the first type of reading is implied. In order to ensure a unique derivation of TAI from a recorded reading of UTC in the vicinity of a positive leap second (where DTAI jumps up by 1 s and the value of TAI for a given value of TAI - DTAI is not unique), the UTC reading that corresponds to the earlier TAI value shall be recorded with a second field = 60 s, and the other UTC reading, with a second field 60 s. Michael Deckers (still trying to understand the topology you referred to) I think we are basically on the same wavelength, though I would turn some of your sentences around. The way UTC is disseminated is not directly relevant to the discussion, and I don't think I said anything about topology. A better way to think about it would be from the combinatorics point of view. Enumerative combinatorics is basically concerned with counting things, usually counting them two ways and drawing conclusions from that. Use of mixed-radix numbers is one of the strategies used in combinatorics, e.g. see http://en.wikipedia.org/wiki/Factoradic. The representation of UTC as a variable-mixed-radix number is a clever way (possibly too clever) of counting seconds of TAI in a way that allows interpretation as either TAI or, approximately, UT1. The UT1 (or time_t) interpretation is obtained by treating UTC's representation (label, notation) at face value, as though it was an ordinary sexagesimal number. UT1 so derived does have a discontinuity when leap seconds are inserted and presumably this is what leads people to say, misleadingly, that UTC itself is discontinuous. On the other hand, TAI is recovered when the variable radix of the seconds field is taken into account. However, since they occur irregularly, this interpretation requires a table containing the full history of changes in the radix. Alternately, the cumulative effect of the table for epochs since the last leap second is conveniently summarized in a number that we call DTAI, usually referred to as TAI-UTC, where UTC here is understood to be the usual mixed-but- fixed-radix sexagesimal representation. So there is plenty of scope for confusion. However, think back to the graph of age vs UTC that I described at the start of this discussion and particularly that each instant of the continuous time axis has a unique UTC representation. Mark Calabretta ATNF
Re: The real problem with leap seconds
On Fri 2006/01/13 14:20:21 -, Michael Deckers wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL Then why can the IERS express UTC in the MJD notation? Good point. The only such usage I am aware of is in IERS Bulletin A where the MJD column is given without saying even whether it's UTC, TAI, UT1, or something else. In fact, in the situation where it's used the accuracy doesn't warrant it. Mark Calabretta ATNF
Re: The real problem with leap seconds
On Fri 2006/01/13 11:45:13 -, Ed Davies wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL If you don't count the leap seconds then the good news is that days are all 86 400 seconds long but the bad news is that the real is undefined during the leap second and there's a discontinuity (or rather, a surprising continuity in that at some point it's 23:59:59.99 and a whole second and a tiny bit later it's 00:00:00.). Agreed. I would add that two occasions when you would do this is in computing UT1 and time_t. The use of the 23:59:60 notation is described in ISO 8601. Is it also specified in TF.460? If so, how do they relate it to the notion of DTAI? In practice, refer to the example I gave on Jan/12. Mark Calabretta ATNF
Re: The real problem with leap seconds
On Fri 2006/01/13 16:45:33 -, Michael Deckers wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL Right, UTC timestamps are ambiguous (in the sense that the ... would have been ambiguous ... corresponding TAI value is not known) in the vicinity of positive leap seconds, and the notation with a second field = 60 s is one (elegant) way to disambiguate. ... had not the variable-radix notation not been introduced. Another way to disambiguate is to record the value of DTAI together with a UTC (or TAI) timestamp. Such a method is standardised in ISO 8601 for denoting offsets from UTC, but only with minute resolution. I seem to remember that Clive Feather once proposed this for an extension to the C programming language. ... where UTC here is taken to be in the usual (fixed-radix) sexagesimal format. Mark Calabretta ATNF
Re: Monsters from the id
On Fri 2006/01/13 18:39:01 CDT, John Cowan wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL The situation with the proposed leap hour is quite different. Given that AEST is defined as UTC+1000, and AEDT as UTC+1100, would someone care to speculate, in terms similar to the above, what will happen when a leap hour is inserted? Perhaps the two scales will be labeled O.S. and N.S., as our anglophone antecessors did when switching from Julian to Gregorian. If you go through the exercise trying to tie leap hours to DST, as I challenged, you will discover that it raises many questions that are not addressed by the leap hour proposal. If you make some plausible assumptions as to how it would operate, with DST starting and ending at the usual times of year and leap hours occurring on new year's eve, I believe you will find it far from simple to do in a rigorous fashion, and that at least one of the timescales is genuinely discontinuous. Mark Calabretta ATNF
Re: Monsters from the id
On Thu 2006/01/12 02:36:44 CDT, John Cowan wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL
We already have that repeated time sequence and gap in much of the world,
and live with it. These repetitions would be no better and no worse;
when a gap is present, the local sovereignty can omit the gap, but this
is not a necessary feature of the proposal.
At the start of daylight saving where I live the clocks are set forward
from 2am to 3am. Naively it looks like there is a gap. Likewise at the
end of daylight saving the hour from 2am to 3am appears to be repeated.
The apparent gaps and repeats are simply an artifact of what happens to
a clock display when you change it to read a different timescale.
Standard time Summer timeLegal time
--
2005/10/30 00:01:58 AEST (: ):
2005/10/30 00:01:59 AEST (2005/10/30 00:02:59 AEDT) AEST
2005/10/30 00:02:00 AEST - 2005/10/30 00:03:00 AEDT AEST/AEDT
(2005/10/30 00:02:01 AEST) 2005/10/30 00:03:01 AEDTAEDT
(: ) 2005/10/30 00:03:02 AEDTAEDT
(: ) ::
(: ) ::
(: ) 2006/04/02 00:02:58 AEDTAEDT
(2006/04/02 00:01:59 AEST) 2006/04/02 00:02:59 AEDTAEDT
2006/04/02 00:02:00 AEST - 2006/04/02 00:03:00 AEDT AEST/AEDT
2006/04/02 00:02:01 AEST (2006/04/02 00:03:01 AEDT) AEST
2006/04/02 00:02:02 AEST (: ):
:(: ):
It should be clear that the gaps and repeats are fictitious, especially
if you think of AEST and AEDT as existing beyond the times when they are
in legal use. Putting it in practical terms, suppose I have a traffic
accident at 0230 on 2006/04/02, what time will the police officer write
in his report? For most times of the year he can omit the timezone spec
because there is no legal ambiguity, but to do so for this specific hour
would be insufficient, he must specify AEDT or AEST.
The situation with the proposed leap hour is quite different. Given
that AEST is defined as UTC+1000, and AEDT as UTC+1100, would someone
care to speculate, in terms similar to the above, what will happen when
a leap hour is inserted?
Mark Calabretta
ATNF
Re: The real problem with leap seconds
On Wed 2006/01/11 10:47:25 -, Michael Deckers wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL At some instant when TAI took a value in the positive leap second between 2006-01-01 + 00 h + 00 min + 32 s and 2006-01-01 + 00 h + 00 min + 33 s (the exact instant is not clear from [ITU-R TF.460-6 2002]), DTAI jumped from 32 s to 33 s; thus, UTC is not a monotone increasing function of TAI either. Here in a topology-free way is what the axis labels of my graph look like during the said leap second insertion: UTC axisTAI axis DTAI 2005/12/31 23:59:58 2006/01/01 00:00:3032 2005/12/31 23:59:59 2006/01/01 00:00:3132 2005/12/31 23:59:60 2006/01/01 00:00:3232 60.932.9 32 60.99 32.99 32 60.999... 32.999... 32 2006/01/01 00:00:00 2006/01/01 00:00:3333 2006/01/01 00:00:01 2006/01/01 00:00:3433 The seconds keep step and the graph has no gaps, jumps or kinks. The only difference between UTC and TAI is one of representation, like the current year which may be represented as 2006 or MMVI but it's still the same year. Mark Calabretta ATNF
Re: The real problem with leap seconds
On Wed 2006/01/11 20:58:25 PDT, M. Warner Losh wrote in a message to: [EMAIL PROTECTED] and copied to: LEAPSECS@ROM.USNO.NAVY.MIL : 60.999... 32.999... 32 :2006/01/01 00:00:00 2006/01/01 00:00:3333 :2006/01/01 00:00:01 2006/01/01 00:00:3433 : : The seconds keep step and the graph has no gaps, jumps or kinks. Shouldn't the DTAI increment for the leap second? It goes from 32 to 33 at precisely 2006/01/01 00:00:00 (UTC) (or at precisely 2006/01/01 00:00:33 (TAI) if you prefer), as shown in the above table. Refer to the last page of the current IERS Bulletin A, Vol. XIX No. 1, ftp://maia.usno.navy.mil/ser7/ser7.dat, which says the same as above though in a little less detail. That's the point of the leap second... Or is that only needed when you do the POSIX time_t thing of repeating 59? My comments on discontinuity etc. do not apply to time_t which is not the same thing as UTC. In computer science, regular things are easy. Irregular ones are hard and prone to errors. The :60 kludge makes a regular 1-1 mapping function for time into a table driven nightmare :-(. It sure does. The point isn't that one can construct a 'second labelling' that is unambiguous, monotonic and increasing, but rather that when one distills the UTC time down to a single number, you necessarily have ambiguities and discontinuties in that function. time_t has ambiguities and discontinuties, but that is not a necessary consequence of leap seconds. To their credit the CCIR did not stuff up in specifying the clock notation to be used for UTC. Mark Calabretta ATNF
Re: The real problem with leap seconds
On Mon 2006/01/09 10:01:27 -, Clive D.W. Feather wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL I've just read through the email that has accumulated on this list since before xmas - impressive volume! Why not devote a fraction of that time and energy to producing a formal position paper. You've expressed it very badly in the article. ...and you've expressed this rather tactlessly! The problem is not that UTC can't be expressed as a real number. Rather (and you do sort of say this, just not very well), the function UTC(TAI) is not continuous and monotonic. I can't let this one pass - UTC is continuous and monotonic. In fact, ignoring differences in origin, UTC = TAI. Surprised? If so then you're confusing a quantity with its representation (though in good company in doing so). First consider a graph of a person's age versus calendar date with a precision of 1 day. The fields in calendar dates are mixed-radix, the day field is also variable-radix depending on the month, and for February the year, so how should we plot the calendar axis? Simple, do it as a count of days and then label it with year, month and day-of- month; Feb/29 in leap years comes out in the wash. As expected, the graph is a continuous straight line of slope 1 - no breaks, no kinks - the person doesn't age in fits and starts! Now consider extending this graph to sub-second precision, accounting for leap seconds, with age to be measured in TAI and calendar date in UTC. Now the date axis must be constructed as a count of seconds of UTC (SI seconds, same as TAI) measured from birth. As before label the date axis using conventional calendar/clock notation. The graph is still a continuous straight line of slope 1 (no breaks, no kinks). Leap seconds are labelled as 23:59:60 - that is the formal representation, each second of UTC has a unique label as required for mathematical validity. (Note that it is incorrect to repeat the seconds count at 59, 00, 01 or anywhere else, even though that may be required on clock displays for practical reasons.) Doing arithmetic on UTC using clock notation is like doing arithemetic on calendar dates or with numbers using Roman numerals. The principle difference is that leap days follow a set rule and computations involving future times can be performed, whereas leap seconds do not follow a set rule and computations cannot be performed into the future. I am reminded of a discussion concerning the curious repetition of 1828 in e = 2.718281828... Simply reexpress the number in base 2, base e, or something else; the pattern disappears. Mark Calabretta ATNF
Re: The real problem with leap seconds
On Mon 2006/01/09 10:38:54 -, Peter Bunclark wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL I't be interesting to do an FFT on this list, and see if some of the contributers actually ever sleep, or do any other work... I had the same thought - the moreso when I reflect on the nil response to my request for a counter-presentation at ADASS. (What sort of FFT did you have in mind?) Cheers, Mark
ABC leapsec article
The RAS statement seems to have generated quite a bit of media comment: http://abc.net.au/science/news/space/SpaceRepublish_1466849.htm Mark Calabretta ATNF
Re: Consensus rather than compromise
On Wed 2005/08/31 07:29:22 +0200, Poul-Henning Kamp wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL If such a system were to be adopted, then in future, in order to determine a historical time, the full record of timezone changes would be needed. How is this different than today ? To determine the civil time in Copenhagen at a specified epoch we take UTC, add the timezone offset then possibly add 1 hour for DST. zoneinfo provides rules for the latter - e.g. DST starts on the first week of March and ends whenever. Currently the timezone offset is essentially fixed for a particular place, yes there are quirks but it's hardly relevant to the argument. Under the proposed scheme, timezone offsets would be a function of epoch as well as place, thus requiring another table for each timezone. However, there would be a fundamental difference between the DST and TZ rules: the former are quantized at 0 or +1, so you can only ever get it wrong by one hour. However, the TZ offset would not be limited in range, over millenia it would span many hours, one hour in the first millenium and accelerating. John Cowan argues that timezones will tend to coalesce as nations reach agreement, but remember that we are talking about timescales of millenia. Over such times nations as a whole don't tend to reach agreement - consider how the Gregorian calendar was adopted piecemeal by different countries (empires really) over centuries. Consider the way the map of Europe has changed since the Roman Empire, or even over the last couple of centuries, or even within our own lifetimes. And consider also the disparate and antagonistic nature of political ideologies in those periods. But the killer is that a timezone only needs to fragment *once* in order to require the creation of a separate TZ rule table. How is it different from having to keep a total history of leapseconds ? The table of leapseconds is a function of time but not place. Mark Calabretta ATNF
Re: Leap seconds BoF
On Wed 2005/08/31 07:30:17 +0200, Poul-Henning Kamp wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL The closest I'll get is Copenhagen Denmark :-( If noone can present your arguments in person then we did also invite a submission. Given the amount of energy expended on this list (far too much for me to keep abreast of!) I would have thought that you might channel some into preparing a few slides. The example of the GPS device in remote Alaska with the atomic clock that loses its antenna, given in a later email by M. Warner Losh might be a good starting point. Can you guys get together behind the scenes and do it? Or must we try to represent your arguments for you? Mark Calabretta ATNF
Re: Consensus rather than compromise
On Tue 2005/08/30 19:46:51 +0200, Poul-Henning Kamp wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL keep the clock as people see it on their wrist [1] in sufficient sync with the light of day through minor acts of timezone adjustments. If such a system were to be adopted, then in future, in order to determine a historical time, the full record of timezone changes would be needed. For general purposes, a record would have to be maintained for every civil administration that sets its timezone (I'm thinking of /usr/share/zoneinfo). This would be a much bigger deal than the current daylight saving switches. Inevitably it also means that the world's timezones would fragment as adjacent civil administrations adopted disparate policies on timezone adjustment. And then, as the political map of the world changes, so the record would become ever more hopelessly complicated. Mark Calabretta ATNF
Leap seconds BoF
Greetings, especially to those in favour of stopping leap seconds! A conference concerning astronomical software is coming up at the start of October and there will be a discussion forum (BoF) on the leap second proposals. The conference (www.adass.org) is mainly directed towards, and attended by astronomical software engineers, a number of whom have contributed to this list. Part of the discussion forum will be to explain the background and reasons for eliminating leap seconds. As a co-organizer it occurred to me that rather than have your views espoused by astronomer-types, who you may imagine to be biassed, that you may wish to present a summary of the reasons why you believe leap seconds must be discontinued. If any of you will be in the vicinity of Madrid in the period Oct/03-05 (the BoF is yet to be scheduled) and would like to give a five to ten minute presentation then we would be delighted to receive it. If you can't attend, but could prepare a half-dozen or so slides (in whatever format you desire), or perhaps some plain text that can be read out, I will undertake to present it, verbatim, on your behalf. As the audience will be scientific/technical in nature, a few well chosen, specific examples that illustrate the technical aspects of your argument would be most effective. Mark Calabretta ATNF
Re: Precise time over time
On Thu 2005/08/11 12:37:52 MST, Rob Seaman wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL As far as the maximum permitted size for DUT1 - some think 0.9 seconds is too small. There appears to be a consensus among quite divergent thinkers here that 0.9 hours is much too big. I imagine most astronomers would be willing to entertain intermediate values. But, thinking particularly of the piece by Jan Meeus (on this list recently via Christian Steyaert), I expect that many astronomers would be quite irritated by that. However, allowing DUT1 to grow potentially to tens of seconds would be more patatable than the current leap hour proposal, so a predefined long-term extrapolation, as described by Steve Allen (Aug/5), seems possible as a compromise. However, the question that naturally arises is the required timescale of the extrapolation. A figure of 50 years seems first to have been suggested by Poul-Henning Kamp (Aug/04, My personal opinion is that 50 years seems right, 20 years might be livable) and since seems to have become set. However, I question the need for such a long extrapolation. What systems being constructed now will need to know the time to the nearest second for 50 years without the possibility of being updated? Cast your minds back to 1955; the state of technology then; what was built then that is still running now. If the extrapolation could be reduced the potential excursion of DUT1 would also be reduced. I think the idea would be much more saleable with an initial timescale of, say, 20 years, extended by 5 years every 5 years. So at any time the extrapolation would range between 15 and 20 years. Mark Calabretta ATNF
Re: Stupid question from programmer: Why not just eliminate ALL UTC corrections ?
On Wed 2005/08/03 22:48:35 MST, Scott Moore wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL The conversion to solar time is done for the user's benefit, and that only needs to be accurate to the second, which is all leap second time gave you in any case. Mostly, yes, but it's conceivable that there will be cases (legal/ financial transactions, etc.) where the time needs to be recorded accurately - assuming that civil/legal time still runs on UTC. Also, over the years the accumulated leap seconds will mount to something significant - a lot more than 24s. Therefore, I believe it would be best to implement procedures to handle this conversion correctly from the start. Anyway, I agree with your basic point that system time be maintained in TAI. Mark Calabretta ATNF
Re: Stupid question from programmer: Why not just eliminate ALL UTC corrections ?
On Thu 2005/08/04 08:18:55 +0200, Poul-Henning Kamp wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL Most if not all modern UNIXes already have the table of leapseconds. Without wishing to imply that the solution is so simple, your answer begs the question: what do you see as the principle difficulty in having systems use TAI internally and maintain a table of leap seconds for conversion to/from civil time? Mark Calabretta ATNF
Asian earthquake effects
May be of interest to this list: ASIAN QUAKE MOVED ISLANDS, SHORTENED DAYS (Environment Nature News, 9/2/05) The massive earthquake that triggered the Asian tsunami wobbled the Earth on its axis, forced cartographers back to the drawing board and changed time by a fraction. But there's no need to adjust your clocks. http://www.abc.net.au/science/news/enviro/EnviroRepublish_1299077.htm Mark Calabretta ATNF
Re: What problems do leap seconds *really* create?
On Wed 2003/01/29 15:43:24 PDT, Rob Seaman wrote in a message to: [EMAIL PROTECTED] Basically we don't have leap seconds because the Earth's rotation is slowing down (by transfering angular momentum to the Moon). Rather, we have leap seconds because the Earth has *already* slowed down since 1900. See the rather consistent slope of about 7 seconds per decade on the plot of UT1-UTC (with leap seconds removed) versus date: ftp://gemini.tuc.noao.edu/pub/seaman/leap/noleap.pdf The current dynamical effects are the subtle wiggles imposed on this trend. This is actually a fairly useful bias since it guarantees (short of asteroid impact or armageddon) that there will be no negative leap seconds. Again, please note how consistent the divergence is between atomic and Earth timescales over decade long periods. Where precisely is the urgency to adopt a quick fix? I agree with you that there is plenty of time to make an informed decision, that nothing need be done on a timescale of decades, and also that the process to date appears, at least to some of us, to have bordered on Machiavellian, though I'm sure it was not. It's also true that the leap-seconds we have now do come from the slowdown since 1900. However, your consistent slope of about 7 seconds per decade obscures the basic point about the long term future of UTC. Your graph shows a linear approximation to what is actually a parabola. The graph in the GPS World article shows the long term trend much better. Though its fit to a parabola is not much more convincing - we do know that it is a parabola because the physics of the Earth-Moon dynamical system tells us so. The wiggles are caused by the motion of dense material in the Earth's mantle which cause the Earth's moment of inertia to vary unpredictably, thus causing it to spin up as well as down. They are what leap-seconds were originally designed to handle, not the predictable, long-term secular deceleration of the Earth's rotation. Thus, what is 7 seconds per decade now will become 35 seconds per decade in another two hundred years time. When you add up all those so-many-seconds per decade over the next 20 decades the cumulative error runs to many minutes - already nearly 60s by 2050 according to the GPS World article, not 35s by a linear extrapolation, and more than 140s by 2100, double the linear-extrapolated value. The cumulative error grows quadratically; that is the problem. Mark Calabretta ATNF
Leap-seconds, the epsilon perspective
scale - computer programmers happy! 4) Cumulative effect of epsilon replaced by a small daily correction - grandchildren's grandchildren happy! 5) No legislative changes required - politicians happy! 6) No effect on religious or sporting calendars - religious and sporting communities happy! 7) Conceptual simplicity - everyone happy!! Why might this not be such a good idea? 1) Leap-second updates replaced by Epsilon updates - user intervention still required (unless non-secular changes in epsilon are ignored). However, the error introduced by a missed, or delayed update would be much less, only a small fraction of a millisecond per day (cumulative). 2) UTC still not predictable indefinitely into the future (unless non-secular changes in epsilon are ignored). 3) The difference between TAI and UTC would no longer be an integral number of (leap) seconds. Historical time calculations would be a little more complicated (unless non-secular changes in epsilon are ignored) because the value of Epsilon and its date of introduction would have to be recorded, rather than just the date of introduction of a leap- second. 4) While digital clock displays would handle this system easily, analogue clock faces (even if digitally driven) might have trouble once epsilon exceeds a few seconds - but that is a long way off. 5) Burden falls on precision clockmakers, and timekeeping software. Why wasn't this done from the start? I believe that the secular deceleration of the Earth's rotation rate was unknown, or poorly understood, in the early 1970s when UTC was introduced. Also at that time, clocks were not smart enough to handle this sort of correction, but now that they are driven by those new-fangled (in 1970s terms) micro-processors it should be relatively easy to implement. Analogue clock faces would have been the norm in the early 1970s, adjusting them for leap seconds would have been simpler. What would be the timescale for such a change? Many clocks (e.g. GPS Time and the clocks at most astronomical observatories) would maintain their best approximation of TAI and software would compute UTC from it using tabulated values of Epsilon (or computed values if non-secular changes in epsilon are ignored). Other clocks might maintain UTC directly using the current value of Epsilon. Either way, the clock and/or software would need changing. Costs would be minimized if the change was incorporated as part of the replacement cycle of precision clocks and timekeeping software. Thus, it depends largely on what the lifetimes of these are; ideally, all such should have been replaced by the time the change was introduced. Thus we may be looking at a multi-decade lead-in. However, there is no rush! What would we tell the public? The Earth is slowing down (friction - sort of) and the days are getting very slightly longer, but you don't have to worry about it unless you need to know the time of day to within a few milliseconds. In particular, Ramadan, Diwali, Pesach, Easter, Hanamatsuri, the World Cup, etc. are not affected, nor are world timezones. And the *really* long term? Millions of years hence, when the mean solar day is 25 SI hours long, epsilon would be one hour but UTC would still function properly. Notably, updates to Epsilon would be as infrequent as ever. However, the world's timezones, especially those furthest from Greenwich, would need a modest adjustment - half an hour at most. Dr. Mark Calabretta Australia Telescope National Facility
