Wikipedia article
Thanks to those who confirmed the ITU text on when leap seconds can be applied. I've made two small edits to the Wikipedia article to correct parts which were wrong or potentially misleading (plus a slightly tongue-in-cheek remark in the discussion page) However, it's a horrible article and really needs reorganization as some of the paragraphs have suffered serious mission creep. I don't even like the first sentence. "Intercalary" seems wrong to me as a leap second is part of the day it is applied to, not between days. I thought about changing it but decided I might be being a bit blinkered in my definition of "intercalary". Thoughts? Ed.
Re: Introduction of long term scheduling
Warner Losh wrote: The IERS bulletin C is a little different than the ITU TF.460: Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date. Unfortunately, these IERS bulletins are dreadfully badly worded and seem to assume current practice rather than fully defining what they mean. E.g., Bulletin C 32, dated 19 July 2006 http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat says: NO positive leap second will be introduced at the end of December 2006. So we still don't know officially if there was a negative leap second then and we still don't officially know if there will be a leap second at the end of this month. http://hpiers.obspm.fr/iers/bul/bulc/BULLETINC.GUIDE says: UTC is defined by the CCIR Recommendation 460-4 (1986). It differs from TAI by an integral number of seconds, in such a way that UT1-UTC stays smaller than 0.9s in absolute value. The decision to introduce a leap second in UTC to meet this condition is the responsability of the IERS. According to the CCIR Recommendation, first preference is given to the opportunities at the end of December and June,and second preference to those at the end of March and September. Since the system was introduced in 1972 only dates in June and December have been used. Again, this is the truth but not the whole truth as it doesn't mention the third preference opportunities at the ends of other months - but it'll be a while until those are needed. (Also, they can't spell "responsibility" :-) Ed.
Re: Introduction of long term scheduling
Steve Allen wrote: On Mon 2007-01-01T21:19:04 +, Ed Davies hath writ: Why does the "One sec at predicted intervals" line suddenly diverge in the early 2500's when the other lines seem to just be expanding in a sensible way? ... I suspect that the divergence of the one line indicates that the LOD has become long enough that 1 s can no longer keep up with the divergence using whatever predicted interval he chose. I suspect that the chosen interval was every three months, for it is in about the year 2500 that the LOD will require 4 leap seconds per year. Yes, that make sense. I worked out what LOD increases he'd have to be assuming for one or 6 monthly leaps and neither seemed right. Should have realised that it was in between. Still, it's a strange assumption, given that TF.640 allows, I understand, leaps at the end of any month. Unofficially, the wording seems to be: A positive or negative leap-second should be the last second of a UTC month, but first preference should be given to the end of December and June, and second preference to the end of March and September. Anybody got access to a proper copy and can say whether that's right or not? If it is right then the Wikipedia article on leap seconds needs fixing. As for the other questions, McCarthy had been producing versions of this plot since around 1999, but the published record of them is largely in PowerPoint. Dr. Tufte has provided postmortems of both Challenger and Columbia as testaments to how little that medium conveys. Indeed, this slide hasn't got us much closer to understanding the original problem, namely: what is maximum error likely to be over a decade. Ed.
Re: A lurker surfaces
Zefram wrote: ... The historical trend is towards using uniform time units. It seems curious now that when the atomic clock was invented astronomers opposed calling it a "time" standard. Well, it seems curious to everybody except Rob Seaman :-) ... It is much like the ancient Egyptians (IIRC) making the transition from sundials to water clocks. They had always marked out hours on sundials subtending equal angles, so the actual temporal length of the hours varied over the course of the day. When the water clock gave them an independent time reference, they were horrified that its uniform hours didn't match sundial hours. Much technical ingenuity went into mechanical modifications to water clocks to make them accurately emulate what went before. ... Nice analogy. Ed.
Re: Introduction of long term scheduling
Steve Allen wrote: On Mon 2007-01-01T17:42:11 +, Ed Davies hath writ: Sorry, maybe I'm being thick but, why? Surely the IERS could announce all the leap seconds in 2007 through 2016 inclusive this week then those for 2017 just before the end of this year, and so on. We'd have immediate 10 year scheduling. For reasons never explained publicly this notion was shot down very early in the process of the WP7A SRG. It would almost certainly exceed the current 0.9 s limit, and in so doing it would violate the letter of ITU-R TF.460. Yes, I was assuming exceeding the 0.9 s limit, as I'm sure the rest of my message made clear. We are discussing this as an alternative to, for all intents and purposes, scrapping leaps altogether and blowing the limit for all time, so I don't see this as a problem. Ed.
Re: Introduction of long term scheduling
Poul-Henning Kamp wrote: If you have subtle point, I'd love to hear it. Not even close to a subtle point, I simply cannot figure out what the graph shows... Me too. Is this an analysis or a simulation? What are the assumptions? What "predicted intervals" does he mean? The bullet points above are very confusing as well. What does "large discontinuities possible" mean? Ignoring any quibble about the use of the word "discontinuities", does he mean more than one leap second at a particular event? Why would anybody want to do that? - at least before we're getting to daily leap seconds which is well off to the right of his graph (50 000 years, or so, I think). Why does the "One sec at predicted intervals" line suddenly diverge in the early 2500's when the other lines seem to just be expanding in a sensible way? Ed.
Re: Introduction of long term scheduling
Rob Seaman wrote: ... Obviously it would take at least N years to introduce a new reporting requirement of N years in advance (well, N years minus six months). Sorry, maybe I'm being thick but, why? Surely the IERS could announce all the leap seconds in 2007 through 2016 inclusive this week then those for 2017 just before the end of this year, and so on. We'd have immediate 10 year scheduling. I suspect it would be exceptionally interesting to everyone, no matter what their opinion on our tediously familiar issues, to know how well these next seven or so leap seconds could be so predicted, scheduled and reported. Absolutely, it would be very interesting to know. I suspect though, that actually we (the human race) don't have enough data to really know a solid upper bound to possible error and that any probability distribution would really be not much more than an educated guess. Maybe a few decades of detailed study has not been enough to see wilder swings - to eliminate the unknown unknowns, if you like. If the 0.9s limit were to be relaxed - how much must that be in practice? Are we arguing over a few tenths of a second coarsening of the current standard? That's a heck of a lot different than 36,000 tenths. Maybe we can turn this question round. Suppose the decision was made to simplistically schedule a positive leap second every 18 months for the next decade, what would be the effect of the likely worst case error? First, what could the worst case error be? Here's my guess. If it turned out that no leap seconds were required then we'd be 6 seconds out. If we actually needed one every nine months we'd be out by about 6 seconds the other way. So the turned around question would be: assuming we are going to relax the 0.9 seconds limit, how much of an additional problem would it be if it was increased by a factor of 10 or so, in the most likely worst case? As Rob has pointed out recently on the list, 1 second in time equates to 15 seconds of arc in right ascension at the celestial equator for telescope pointing. Nine seconds in time is therefore 2.25 arc minutes. For almost all amateur astronomers this error would be insignificant as it's smaller than their field of view with a normal eyepiece but, more importantly, the telescope is usually aligned by pointing at stars anyway rather than by setting the clock at all accurately. For the professionals I'm not so sure but, for context, Hubble's coarse pointing system aims the telescope to an accuracy of about 1 arc minute before handing off control to the fine guidance sensors. For celestial navigation on the Earth, a nine second error in time would equate to a 4.1 km error along the equator. Worth considering. My guess would be that there would be applications which would need to take account of the difference which currently don't. Is it really likely to be a problem, though? Remember that this is not a secular error, by the end of, say, 2009 we'd be beginning to get an idea of how things are going and would be able to start feeding corrections into the following decade. So, while it would be nice to know a likely upper bound on the possible errors, is a back of an envelope guess good enough? Happy perihelion, Ed.
Re: A lurker surfaces
Poul-Henning Kamp wrote: In message <[EMAIL PROTECTED]>, Rob Seaman writes: Jim Palfreyman wrote: Just a reminder that UTC has no - none - nada - discontinuities. Various computer mis-implementations may, but the standard is very carefully constructed to avoid spring-forward or fall-back gaps or do- overs. Rob, If you feel uncomfortable with calling leapseconds discontinuities, then we can use the term arrhythmia instead. If we assume that every month has 30 days and obtain a day number by multiplying the month number by 30 and adding the day in month (call this the SDN - Silly Day Number) and then look at SDN-MJD (modified Julian day number) we would see discontinuities. The only way to see discontinuities in UTC-TAI is by making an equally silly assumption in numbering the seconds of UTC: assuming all UTC minutes are 60 seconds or, equivalently, all UTC days are 86 400 seconds. The unfortunate thing is that people actually do think of it this way. E.g.: http://hpiers.obspm.fr/eop-pc/earthor/utc/TAI-UTC_tab.html The whole idea of the expression UTC-TAI being meaningful and evaluating to a number of seconds is a convenient but rather sloppy shorthand. Any strongly typed programming language ought to give a type error on that expression. UTC times of day are variable radix - in just the same way as days and months are in the Gregorian calendar. Except, of course, that the Gregorian calendar is fixed and completely predicable. I have an awful lot of sympathy for the idea of making leap seconds predictable over longer periods, even if it risks UTC-UT1 becoming larger than at present allowed. Ed.
Re: Mechanism to provide tai-utc.dat locally
M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> John Cowan <[EMAIL PROTECTED]> writes: : M. Warner Losh scripsit: : : > If I was to compute the number of seconds between Jan 1, 2007 0:0:0 and : > Dec 31, 2008 23:59:50, the answer is 63071990 or 63071991 or 63071992. : > We have no way of knowing today how many seconds are in that interval. : > We do know the answer is one of the above. : : Technically 63071999 and 63071998 are also possibilities, though : I admit they are unlikely. you are correct... this simple stuff sure is hard... How can 63071999 fit in? Wouldn't it be 63071989 for a single negative leap second accepting Warner's numbers? That's all of the seconds in 2007 and all but the last 9, 10 or 11 seconds in 2008, right? Then I get: 63 158 387 63 158 388 63 158 389 63 158 390 63 158 391 63 158 392 or 63 158 393 assuming continuation of the Gregorian calendar so 2007 is not a leap year but 2008 is and positive or negative leap seconds only at the end of 2007-06, 2007-12 or 2008-06. Bulletin C 32 (which appears to be current) says no positive leap second at the end of 2006-12 (so we'd assume also no negative leap second at that time, too) but says nothing of 2007-06 or later. Bets against 63 158 387? Ed.
Re: Mechanism to provide tai-utc.dat locally
Ashley Yakeley wrote: ... This has led me to consider run-time methods of obtaining leap-second information, and how that might be standardised for use by software authors. For instance, I imagine a software package that established a well-known place in the directory hierarchy to find tai-utc.dat and perhaps other "earth data" files, and was responsible for keeping them up to date. Other software could then make use of the package without each having to implement their own mechanism. Does this strike people as worthwhile? Does anyone know of an existing effort along these lines? ... Hi Ashley, Welcome to the leap second list. Yes, I think providing leap second information in easily accessible form is worthwhile - and pretty much key to living with leap seconds if the decision is made to continue with them. A while ago I proposed the (ab)use of the DNS to do this. http://www.edavies.nildram.co.uk/dns-leapseconds/ Obviously, that's not quite the same as having the information available locally but there's an overlap. It would at least be a source to automatically update the local information when a system is connected. Ed Davies.
Re: what time is it, legally?
Rob Seaman wrote: I'm given to wonder how much of the friction on this mailing list is simply due to the shortcomings in the technology that implements it. I've appended a message I sent in August with four plots attached. Can someone tell me whether it is readable now or was successfully delivered back then? I rummaged around on the list archive and on archives accessibly via google and find no copy of this message that survived the communications medium. In Thunderbird on Ubuntu Linux it looked fine in both your original post and the repeat you attached - so any problems are down to the reader and not the transmission, I think. Ed.
Re: how posterity will measure time
Rob Seaman wrote: > ... An amateur astronomer with a Celestron, the Astronomical Almanac and an atlas can recover UTC anywhere on Earth. ... Do you really mean UTC here? I can see that an amateur with a Celestron could recover UT (for some flavour of UT, I'm not sure which - UT0?, then presumably UT1 after traveling around a bit) but where does the delta T come from to get UTC? ... Unplug the atomic clocks for a few seconds (which may be taken as the definition of a "discontinuity in higher civilization"), and even the professional timekeepers who built the devices would be unable to recover TAI. ... Actually, assuming somebody remembered to make a note of TAI-UTC before forgetting to put a shilling in the meter for the atomic clock TAI is exactly as recoverable as UTC in the short term when it's possible to work out the number of leap seconds which would have been inserted or removed. Longer term it would be harder, of course, but why would that matter? Ed.
Re: ADASS poster on UTC
Steve Allen scripsit: For most civil purposes time is only relevant to the nearest minute; John Cowan replied: An obvious counterexample is taping TV shows: you don't want to miss the first or last minute (modulo the presence of commercials). I go to some trouble to keep my VCR synchronized with NTP time to the nearest second or two. An obvious example is taping TV shows: you don't want to miss the first or last minute (modulo the presence of commercials). When I used to watch TV I went to some trouble to start recording a minute or so before the scheduled start time of the program and to continue recording for a few minutes afterwards. Sorry for the sarcastic looking format: the symmetry of the argument just appealed to me. Ed.
Re: independence day
Poul-Henning Kamp wrote: In message <[EMAIL PROTECTED]>, Steve Allen writes: In the middle of May some text about legal time in the US was introduced into a US Senate bill regarding funding for NSF and NIST. See section 508 of S.2802 introduced 2006-05-15, e.g. http://thomas.loc.gov/cgi-bin/query/z?c109:S.2802: `(b) COORDINATED UNIVERSAL TIME DEFINED- In this section, the term `Coordinated Universal Time' means the time scale maintained through the General Conference of Weights and Measures and interpreted or modified for the United States by the Secretary of Commerce.'. That could sound like the drilling of a loophole :-) It could just be intended to allow for the distinction between UTC(NIST) and postal UTC. Ed.
Re: building consensus
Rob Seaman wrote: On Jun 7, 2006, at 2:03 AM, Clive D.W. Feather wrote: In the UK in 1750, there were two different Julian calendars in use: the day and month enumeration matched, but year numbers changed at different dates (1st January in Scotland, 25th March in England and Wales). I've heard this said, but what exactly does this mean from the point of view of the people of the time? Could see how the 1st of any month would be as good as any other for marking the count of years. But presumably you are saying something like that the sequence of dates was: 22 March 1750 23 March 1750 24 March 1750 25 March 1751 26 March 1751 27 March 1751 Right? Yes, I think that's right. And, as I understand it, we still keep that change of year in mid-month but now it's on April 5th for the change of tax year. When we switched from the Julian to the Gregorian calendar the tax year was kept the same length so its date changed. The tax year we're now in is designated as 2006/07, though, to avoid confusion. Ed.
Re: building consensus
Rob Seaman wrote: Doubt I can lay my hands on the copy of ISO 8601 from my Y2K remediation days. Anybody want to comment on whether it actually attempts to convey the "Gregorian" algorithm within its pages? Yes, it does. This International Standard uses the Gregorian calendar for the identification of calendar days. The Gregorian calendar provides a reference system consisting of a, potentially infinite, series of contiguous calendar years. Consecutive calendar years are identified by sequentially assigned year numbers. A reference point is used which assigns the year number 1875 to the calendar year in which the “Convention du mètre” was signed at Paris. The Gregorian calendar distinguishes common years with a duration of 365 calendar days and leap years with a duration of 366 calendar days. A leap year is a year whose year number is divisible by four an integral number of times. However, centennial years are not leap years unless they are divisible by four hundred an integral number of times. This is from section 4.3.2.1 of the final draft of ISO8601:2000. It's also an interesting quote in that it suggests that the 1875 Convention du mètre is important in the international definition of the Gregorian calendar. Anybody know more on that? Ed.
Re: 24:00 versus 00:00
Ed Davies scripsit: If only the 24:00 for end of day notation wasn't in the way we could look at positive leap seconds as just being the result of deeming certain days to be a second longer than most and just use 24:00:00. We wouldn't have to muck with the lengths of any of the hours or minutes within that day. John Cowan replied: That amounts to saying that some days have 24 hours, whereas others have 25 hours, 24 of them being 3600 seconds long and the 25th being 1 second long. IMHO that is worse. No, it amounts to saying that some days are 24 hours and 1 second long. When you're half a second from the end of such a day you are 24 hours, zero minutes and half a second from the start. If you had a 1'6" piece of string you wouldn't say it's a two foot piece of string but the second foot is only 152.4 mm long. (Well, I think you wouldn't, though I think some politicians might.) As Rob has just pointed out in a parallel thread 23:59:60.5 and 24:00:00.5 can be treated as equivalent. It just seems to me that the second of these notations fits in with the normal use of sexagesimal somewhat better. Ed.
Re: 24:00 versus 00:00
Markus Kuhn wrote: With the 24-h notation, it is a very useful and well-established convention that 00:00 refers to midnight at the start of a date, while 24:00 refers to midnight at the end of a date. Thus, both "today 24:00" and "tomorrow 00:00" are fully equivalent representations of the same point in time. Writing "24:00" to terminate a time interval at exactly midnight is pretty common practice and is even sanctioned by ISO 8601. I agree with all that is written here - the 24:00 notation is indeed both useful and well-established and is sanctioned by ISO 8601. However, it raises a point which has been floating around in the back of my head for a while. The problem is that this notation means that we can't have second identifiers after 23:59:59 in sexagesimal - we have to break out of that system to use 23:59:60 which seems quite ugly, at least to me. If only the 24:00 for end of day notation wasn't in the way we could look at positive leap seconds as just being the result of deeming certain days to be a second longer than most and just use 24:00:00. We wouldn't have to muck with the lengths of any of the hours or minutes within that day. This would scale much better when, eventually, days get longer than 86401 seconds. Presumably before that, it'd also work better for Martian days going to 24:39 and however many seconds it is. Ed.
Re: Accommodating both camps
James Maynard wrote: I wonder, though, whether those in the other camp would find it acceptable to have the standard time and frequency stations not only broadcast UTC and DUT1 (= UT1 - UTC, to 0.1 s resolution), but also to broadcast DTAI (= TAI - UTC, 1 s resolution)? A full implementation needs not just the current DTAI value but also the full history, for conversion of past date/times. Ed.
Re: the tail wags the dog
Rob Seaman wrote: All proposals (other than rubber seconds or rubber days) face the same quadratically accelerating divergence between clock and Earth. By "rubber seconds" you, presumably, mean non-SI seconds. What do you mean by "rubber days"? I'd guess you mean days which are divided into SI seconds but not necessarily 86 400 of them. Just to be clear, is that right? Ed.
Re: the tail wags the dog
James Maynard wrote: The problem is not that the SI second is not based on a natural phenonemon (it is), but that the periods of the various natural phenonema (rotations of the earth about its axis revolutions of the earth about the sun, revolutions of the moon around the earth, etc.) are both incommensurate and changing. Not to mention the hyperfine wibbles of caesium-133.
Re: Approach to leap second discussion
Rob Seaman wrote: I hope we can all continue this discussion in a more positive manner. I'm of the opinion that messages on this list (no matter how "tricky" :-) are always positive. Timekeeping is a fundamental issue. It would be remarkable if there weren't diverse opinions. Any negative aspects of this discussion are related to those who don't choose to participate. Which is to say, those who claim to have decision making authority over UTC at the ITU, for instance. The folks on this list appear to cluster into two groups (speak up if your opinion diverges from both): 1) Civil time should remain layered on UTC. UTC should remain largely unchanged. Leap seconds should continue. and 2) Civil time should be layered on some flavor of interval time. That timescale might be a variation of TAI called TI. TI will not have leap seconds. OK so far. Actually, I've yet to see any argument which would make me deeply unhappy with either of these outcomes. The proposal submitted to the ITU is neither of these. It is: 3) Civil time should remain layered on UTC. UTC should be modified to no longer be a useful approximation to "universal time". Leap seconds will be issued 3600 at a time. You all know where I stand - but there are worlds of difference between #2 and #3 as alternatives to #1. All three proposals face the same looming quadratic emergency. Again, OK so far except perhaps a quibble that it seems to be widely expected that the leap hour probably would never happen. What bothers me about this discussion is that we don't seem to be able to get beyond bouncing backwards and forwards between 1 & 2. As soon as anybody puts up any proposal for further detail with respect to either of these possible outcomes almost all of the response comes back in the form of arguments for the other outcome rather than sensible discussion of the idea in itself. Maybe for the next little while we should assume one or other outcomes each week (1 in odd ISO 8601 numbered weeks, 2 in even numbered weeks) and carry on all the discussion in that context. Ed.
Approach to leap second discussion
The way I think exploration in this group should be going is to seriously examine what engineering steps can be taken to deal with leap seconds properly. This means looking at changes to Posix and NTP, new protocols for disseminating leap second information, new APIs for accessing clock information with different properties and so on. Also, possible changes to leap second scheduling to give longer notice. If, taking all of those together, we find that there are important use cases which cannot be covered then we've made a good case for scrapping leap seconds. The obverse is to look at the use cases (e.g., in astronomy and navigation) which require UT1 (or other Earth orientation information) and look at ways for them to recover that from an atomic timescale. If there are, again, any important use cases which cannot be covered then there's a good case for keeping leap seconds. My suspicion is that actually all cases are reasonably easy to deal with with only a little care. In that case, it becomes an engineering trade-off - which of keeping or scrapping leap seconds causes the least hassle. Starting from a clean slate, I'd guess that doing without leap seconds would be the right answer - at least now, though probably three decades ago the right decision was made for that time. On the other hand, they're here now and I'm far from sure that change would be worthwhile and we don't know for sure what the balance will be in another three decades. What isn't helpful is to have two groups each starting from an assumption or even definition that one or other answer is right repeatedly shouting past each other - particularly using arguments which are tricky to the point of dishonesty, blunt rudeness, personal attacks and so on. I hope we can all continue this discussion in a more positive manner. Ed.
Re: NOT A cruel fraud!
Earlier, I wrote:
We all know that it (and any other world-wide timescale) is
"postal" at the level of the time it takes light to cross a
moderately small room but for microsecond precision and looser
this is not an issue.
I ought to qualify that. There are, of course, time scales which
are synchronized across the world with much better than microsecond
precision (e.g., GPS time) but it's my understanding that they are
not anything like as uniform as TAI. Is this right? Can anybody
quote accuracy information for GPS time? At what level of precision
do time transfers using GPS time need out-of-band ("postal")
correction for uniformity?
This is all not directly relevant to convenient day-to-day civil
time but I think it'd be interesting to know better where the
boundaries are.
Ed.
Re: NOT A cruel fraud!
M. Warner Losh wrote: : > TAI is specifically contraindicated as a time : > scale. : : > TAI is not currently recommended by its creators as a viable time : > scale. : > : : These claims are intellectually fraudulent. The archives in fact support : the opposite of what Mr. Losh contends. Actually, it isn't quite that cut and dried. OK, so why is TAI contraindicated then? I've been on this list since 2002-07 and not yet seen a good argument against it. We all know that it (and any other world-wide timescale) is "postal" at the level of the time it takes light to cross a moderately small room but for microsecond precision and looser this is not an issue. Ed.
Re: Internet-Draft on UTC-SLS
Ed Davies: Appendix A argues against putting the adjustment interval after the leap second (method 4a) by pointing out that some time signals contain announcements of the leap second before it happens but not after. Rob Seaman: Right, ... Ed Davies: I think a stronger argument against this method of adjustment is that during positive leap seconds UTC and UTC-SLS would be indicating different dates: Rob Seaman: This may be a fact - it does not itself constitute an argument. An argument would have to answer the question: So what? You're right - I left the denouement implicit. With this method (4a) UTC-SLS would not have the property listed in section 3: "the time always equals UTC at full or half hours". I think this is a valuable property; as the text following the 4a), 4b) and 4c) options notes: "...would be reached at midnight, which is a time commonly used to schedule events and deadlines." I hope that makes sense. Ed.
Re: Internet-Draft on UTC-SLS
Markus Kuhn wrote: A new Internet-Draft with implementation guidelines on how to handle UTC leap seconds in Internet protocols was posted today on the IETF web site: "Coordinated Universal Time with Smoothed Leap Seconds (UTC-SLS)", Markus Kuhn, 18-Jan-06. (36752 bytes) http://www.ietf.org/internet-drafts/draft-kuhn-leapsecond-00.txt Accepting that UTC-SLS is not the right choice for some applications and that operating system APIs should be very clear on what timescales are being served up in different cases, I think UTC-SLS is a valuable contribution and a good choice for the default timescale for quite a lot of systems. In particular, it would be a good substitute in current APIs which claim to return UTC but actually don't handle leap seconds. Appendix A argues against putting the adjustment interval after the leap second (method 4a) by pointing out that some time signals contain announcements of the leap second before it happens but not after. I think a stronger argument against this method of adjustment is that during positive leap seconds UTC and UTC-SLS would be indicating different dates: UTC UTC-SLS(A.4a) 2005-12-31 23:59:58 2005-12-31 23:59:58 2005-12-31 23:59:59 2005-12-31 23:59:59 2005-12-31 23:59:60 2006-01-01 00:00:00 2006-01-01 00:00:00 2006-01-01 00:00:00.999 2006-01-01 00:00:01 2006-01-01 00:00:01.998 (Exact fractional times depending on whether the correction interval starts at the start or the end of the leap second). This is a pity, in my opinion, because I think it would be nice to leave open at least the option of implementing UTC-SLS as simply "steer your clock towards UTC at the rate of 1ms per second" though I understand that that wouldn't be the right choice in many cases. Ed.
Re: The real problem with leap seconds
Poul-Henning Kamp wrote: In message <[EMAIL PROTECTED]>, Francois Meyer writes: On Mon, 16 Jan 2006, Mark Calabretta wrote: 1. UTC and TAI share the same rate, the same origin, the same second. And therefore : UTC - TAI = 0 This is wrong, plain and simple wrong. Well, if by "UTC" you mean the count of seconds including leaps then this is right. Please don't come back until you have understood and accepted that this is not the case. Please don't be so rude - it really doesn't help to have conversations so polarised. Ed.
Re: The real problem with leap seconds
Markus Kuhn wrote: Ed Davies wrote on 2006-01-13 11:45 UTC: The use of the 23:59:60 notation is described in ISO 8601. Is it also specified in TF.460? It originally comes from ITU-R TF.460, which is a standard for radio time signals. OK, thanks. Ed.
Re: The real problem with leap seconds
Michael Deckers wrote: Sort of like, is it a particle or a wave? :-) At the risk of being misunderstood as sarcastic: if users of UTC were really expected to understand such strange concepts (Schrodinger time) I would plead for the immediate abolishment of UTC. Why cannot UTC be simply taken as the reading of a clock that runs at the same rate as TAI and that is is set back by a second every once in a while? Not really Schrodinger time - just time which you can usefully think of in different ways for different purposes. UTC can be taken the way you suggest most of the time (and that's clearly the way TF.460 wants to think of it), but it is then not well defined during the leap second itself. To deal with that properly you have to either: 1) think of a count of UTC milliseconds or whatever (including those in the leap second) which is then the same as TAI or 2) work in separate fields with a 61 second minute. The truth is that UTC only really makes sense as a year, month, day, hour, minute and second value. Years have 12 months, months have 28, 29, 30 or 31 days, days have 24 hours, hours have 60 minutes, minutes have 59, 60 or 61 seconds. Then why can the IERS express UTC in the MJD notation? We've recently had a question about this on this list which wasn't answered clearly. MJD 27123.5 means 12:00:00 on day 27123 if it's not a leap second day, but what does it mean on a day with a positive leap second? 12:00:00.5? I think it only works if that level of precision doesn't matter but maybe some document somewhere has a convention. Thanks for the further notes from TF.460. Ed.
Re: The real problem with leap seconds
Michael Deckers wrote: I believe I'm now grasping what you mean: the rate of UTC is the same as the rate of TAI (since 1972), that is, the derivative d( UTC )/d( TAI ) = 1. ... This conversation is making something of a meal of a simple point. You can treat UTC as a real in either of two ways: 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.). If you do count the leap seconds then that real is the same as TAI but the days it's divided up into aren't all 86 400 seconds long. Sort of like, is it a particle or a wave? :-) The truth is that UTC only really makes sense as a year, month, day, hour, minute and second value. Years have 12 months, months have 28, 29, 30 or 31 days, days have 24 hours, hours have 60 minutes, minutes have 59, 60 or 61 seconds. 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? Ed.
Re: Monsters from the id
Rob Seaman quoted: Operational rules (after UTC 21 December of the transition year) 1 Tolerance The difference of UT1 from UTC should not exceed ±1h. 2 Adjustments to UTC 2.1Adjustments to the UTC time-scale should be made as determined by the IERS to ensure that the time-scale remains within the specified tolerances. 2.2The IERS should announce the introduction of an adjustment to the UTC time-scale at least five years in advance. At the time of the announcement the IERS should provide directions regarding the details of the implementation of the adjustment. 2.3All operational rules and nomenclature prior to UTC 21 December of the transition year given above no longer apply. NOTE 1 – The broadcast of DUT1 will be discontinued. NOTE 2 – Predictions of the Earth’s rotation currently indicate that such an adjustment would not be required for thousands of years. There's nothing in this text which would stop the IERS continuing to issue leap seconds as they do now except they'd have to do it five years in advance so would, presumably, have to relax the ±0.9 seconds requirement somewhat. Ed.
Re: The real problem with leap seconds
Poul-Henning Kamp wrote: Well, the BIPM doesn't really want anybody to use TAI, their director said as much last year, and I can see where he is coming from on that one. Ed Davies asked: Since the usual response of the pro-leap second lobby to people who want a uniform timescale is "use TAI" this is significant. Do you have any information or references on why the BIPM director said this? Poul-Henning Kamp replied: As I understood it, it was mainly that TAI is a post-factum "postal" timescale. Well, yes, at well below the one microsecond level (10s of nanoseconds I think). The same would apply to UTC, of course, given that it's defined by an offset from TAI and I doubt he meant the world should stop using UTC. Of course, in the real world people don't directly use UTC anyway - they use UTC(NIST) or UTC(NPL) or whatever local approximation is good enough for their purposes. This would be true for any timescale. Ed.
Re: The real problem with leap seconds
Wow, things have got really stirred up around here. Lots of interesting points but I'll just concentrate on one... Poul-Henning Kamp wrote: Well, the BIPM doesn't really want anybody to use TAI, their director said as much last year, and I can see where he is coming from on that one. Since the usual response of the pro-leap second lobby to people who want a uniform timescale is "use TAI" this is significant. Do you have any information or references on why the BIPM director said this? Ed.
Re: The real problem with leap seconds
Michael Sokolov wrote: Hello, I am a new entrant into the leap second debate and I have just written a paper in which I have outlined what I think is the real problem with UTC and leap seconds as they are currently implemented and a proposed solution. I have put the article on my web page: http://ivan.Harhan.ORG/~msokolov/articles/leapsecs.txt The short summary is that I believe the root problem is not the adjustments made to the civil time scale to match Earth's rotation, but the fact that UTC is not expressible as a real number. UTC is expressible as a real number in just the same way that Gregorian dates (with months with different lengths and leap days) can be with the Julian calendar. There's no difference in principle between converting from a TAI time in seconds since some epoch to a UTC date/time in days, hours, minutes, seconds and fractions of a second and converting from an MJD day number to a Gregorian date in years, months, days and fractions of a day. (There's a small difference in practice in that the UTC to TAI conversion requires a lookup table which is not known very far into the future whereas the Gregorian calendar is defined algorithmically for all time.) You are sort of right, though, in that where computer systems typically get screwed up is in trying to assign a number to UTC seconds which is both a count since some epoch but also able to be taken modulo 86 400 to give a day number. This is, of course, impossible. What Markus Kuhn's UTS proposal was about was trying to reach a standard compromise which worked for such software - typically in cases where uniquely labeling the times of events is more important than exact interval determination. Ed.
Re: The real problem with leap seconds
Poul-Henning Kamp wrote: What a weird concept... Why not go the full distance and define a timescale for each particular kind of time-piece: and give each of them their own unique way of coping with leapseconds ? Ignoring the ridiculous parody - no, it's not a weird concept. Different timescales are useful for different purposes. Get used to it. The question is, where in the range of possible timescales is it most useful to put civil time. Ed.
Re: The real problem with leap seconds
Steve Allen wrote: On Sat 2006-01-07T07:39:58 +, Michael Sokolov hath writ: http://ivan.Harhan.ORG/~msokolov/articles/leapsecs.txt If I read it right you have reinvented Markus Kuhn's UTS as seen in http://www.cl.cam.ac.uk/~mgk25/uts.txt http://www.cl.cam.ac.uk/~mgk25/time/leap/ http://www.cl.cam.ac.uk/~mgk25/time/leap/utc-torino-slides.pdf That's my reading too, except that Markus proposed batches of about 1000 UTS seconds either approximately 1.001 or 0.999 SI seconds long which seems like a better idea to me. Also, Markus wasn't proposing UTS as a civil timescale but just for use within computer systems, etc. Ed.
Re: civil time = solar time
Rob Seaman wrote: I said: all parties must certainly agree that civil time (as we know it) IS mean solar time. Ed says: saying that it "IS" civil time is probably a bit strong. "Probably a bit strong" is not precisely a staunch denial. It's not meant to be a staunch denial. I'm mostly supporting your argument - just trying to tone down one aspect which I think is overstated to avoid giving rehetorical ammunition to those who see things otherwise. Ed.
Re: Longer leap second notice
Rob Seaman wrote: Little support - and again, to a certain level of precision (easily better than a second per day), all parties must certainly agree that civil time (as we know it) IS mean solar time. We've got a bunch of time scales here: - apparent solar time. - mean solar time. - local civil time. - international civil time. The main requirements for local civil time for the bulk of its users are that: 1. local civil time matches apparent solar time roughly (e.g., the sun is pretty high in the sky at 12:00 and it's dark at 00:00). 2. the relationship between local civil time and apparent solar time is constant enough in any one place (e.g., if it's sometimes noon at 10:45 local somewhere in eastern China then it should be noon around 10:45 every day there, +/- half an hour or so). 3. the rate of local civil time is constant at least to the precision of most clocks and watches. 4. the relationship between local civil time and international civil time should be predicatable and easy to calculate with (e.g., round numbers of hours or, if somebody insists, minutes). Points 1 and 2 are similar but not quite the same. If, for example, the whole world used GMT then 2 would be true everywhere but 1 would only be true around the prime meridian. Mean solar time isn't really of much interest to anybody, except indirectly. It acts as a more or less constant rate approximation to apparent solar time (requirements 2 and 3). If we lived on a planet with an equation of time which gave much wider swings in the difference between apparent and mean solar time we might have clocks with variable rates - like they had for the stage coaches in Britain before GMT except you'd use the different rates in spring and autumn or whenever, not when you're going east or west. We'd do that if we thought requirements 1 and 2 trumped 3. In summary - it is convenient to have a civil timescale which is both constant rate and a reasonable approximation of apparent solar time. Mean solar time fits that bill if you don't look too closely at the constant rate aspects but saying that it "IS" civil time is probably a bit strong. Ed.
Re: Longer leap second notice, was: Where the responsibility lies
Poul-Henning Kamp wrote: If we can increase the tolerance to 10sec, IERS can give us the leapseconds with 20 years notice and only the minority of computers that survive longer than that would need to update the factory installed table of leapseconds. Rob Seaman replied: No. Rather all computers that exist during such an event are obligated to deal with it. The number of deployed systems follows some increasing trend similar to Moore's law. By delaying the adjustments, you guarantee that more systems will be affected when they do occur. And, unless you can guarantee that a particular deployed system (and systems derived through various upgrade pathways) will be retired prior to the adopted horizon, prudent policy would require remediation in any event. Would like to see a proposed architecture a little more detailed than a "factory installed table". PHK can reply for himself here but, for the record, I think RS's reading of what he said is different from mine. My assumption is that PHK is discussing the idea that leaps should be scheduled many years in advance. They should continue to be single second leaps - just many more would be in the schedule pipeline at any given point. Obviously, the leap seconds would be scheduled on the best available estimates but as we don't know the future rotation of the Earth this would necessarily increase the tolerance. In theory DUT1 would be unbounded (as it sort of is already) but PHK is assuming that there'd be some practical likely upper bound such as 10 seconds. Am I right in this reading? Ed.
Re: went pretty dang smoothly at this end
Keith Winstein wrote: Some minor glitches: (a) My Garmin 12XL GPS receiver (software version 4.53) did not register the leap second on its time display. It went from 58 to 59 to 00, and stayed one second ahead for the next few minutes until I rebooted it. Then it came up correctly. Interesting. My 12XL (software version 4.60) dealt with the leap second pretty well, I thought. It seemed to hold at 23:59:59 for two seconds. More details: http://www.edavies.nildram.co.uk/gps12xl-leapsecond/ Ed.
Re: Software requirements
I wrote: >>2b. give lip service to leap hours for now but actually be leap >>free in practice. Poul-Henning Kamp wrote: Four really, some of us say: 3. Realize that the Earth is a lousy clock and go entirely atomic. But for all practical purposes the difference between 2b and 3 is not something I (need to) care about. Agreed that there's no difference for practical purposes, but what differences do you have in mind for impractical purposes? Just when the paper work gets done or something more? Ed.
Re: Software requirements
Rob Seaman wrote: ... Two options are currently being debated - leap seconds or leap hours. ... Yes - but I thought there was the idea floating around that in practice the powers that be would chicken out before actually implementing the leap hour. Instead they'd leave international civil time (or whatever you want to call it) leap free and instead muck with the offsets between that and local civil times (as is currently done for daylight saving). My understanding is that the US proposal for leap hours is a bit of bureaucratic subterfuge because UTC is supposed to be related to UT. They'd have to get changes to higher level documents or something to cancel that. So I'd say there are really three options being debated: 1. leap seconds. 2a. leap hours. 2b. give lip service to leap hours for now but actually be leap free in practice. The choice between 2a and 2b can be deferred for a couple of centuries. Ed.
Lighter Evenings (Experiment) Bill [HL]
Not strictly on topic but probably of interest - a Bill in the UK House of Lords which I just came across when looking for something else: http://www.publications.parliament.uk/pa/ld200506/ldbills/048/06048.1-i.html A Bill To Advance time by one hour throughout the year for an experimental period; and for connected purposes. Well, at least we'd be in sync with most of the rest of the EC. Don't know if it'll get anywhere, of course. Ed Davies.
Re: a system that fails spectacularly
Poul-Henning Kamp wrote: ... Some of us have been trying to drive this point though for some time: 99.99% of all programmers have no idea what a leap-second is. ... The Java Date class documentation does, at least, show reasonable awareness of leap seconds: http://java.sun.com/j2se/1.5.0/docs/api/java/util/Date.html Pity those of us who've been reading this list a little too long can pick a few minor holes but it's basically reasonable stuff - much better than ignoring leap seconds. Ed Davies.
Re: a system that fails spectacularly
Francois Meyer wrote: I hardly understand how it is reasonably possible to use a GPS-derived UTC without taking into account the leap second information from the GPS navigation message. Unless the unit gets the UTC-GPS offset from the receiver just once at hardboot time and then forget about leap secs... Puzzling. I doubt the unit deals with GPS time at all. Probably it sets its own clock to the UTC value reported by the receiver, leaving all handling of GPS time, UTC-GPS offsets, leapseconds, etc, to the GPS receiver. Then, when the GPS receiver updates its UTC estimate by one second early in the new year the unit's clock is suddenly out by a second. The fact that they write that UTC is adjusted in the first few minutes of 2006 is a clue. Of course, the adjustment really happens in the last minute of 2005. At a previous leap second (1995/96) I logged the NMEA output of a Garmin 100 GPS receiver. This (fairly old) receiver outputs fix information once every two seconds. The change from odd numbered to even numbered seconds happen a few fixes after midnight: $GPRMC,235959,A,5137.56,N,00047.48,W,001.6,019.7,311295,,*07 $GPRMB,AV*71 $GPR00,,*45 $GPGLL,5137.56,N,00047.48,W*75 $PGRMA,437,f,2*01 $GPXTE,A,A,,,N*3C $GPBWC,235959,,T,,M,,N,*17 $GPRMC,01,A,5137.56,N,00047.48,W,001.5,021.4,010196,,*0E $GPRMB,AV*71 $GPR00,,*45 $GPGLL,5137.56,N,00047.48,W*75 $PGRMA,437,f,2*01 $GPXTE,A,A,,,N*3C $GPBWC,01,,T,,M,,N,*17 $GPRMC,03,A,5137.56,N,00047.48,W,001.6,024.1,010196,,*0F $GPRMB,AV*71 $GPR00,,*45 $GPGLL,5137.56,N,00047.48,W*75 $PGRMA,437,f,2*01 $GPXTE,A,A,,,N*3C $GPBWC,03,,T,,M,,N,*15 $GPRMC,05,A,5137.56,N,00047.48,W,001.7,026.7,010196,,*0C $GPRMB,AV*71 $GPR00,,*45 $GPGLL,5137.56,N,00047.48,W*75 $PGRMA,437,f,2*01 $GPXTE,A,A,,,N*3C $GPBWC,06,,T,,M,,N,*10 $GPRMC,07,A,5137.56,N,00047.48,W,001.6,025.8,010196,,*03 $GPRMB,AV*71 $GPR00,,*45 $GPGLL,5137.56,N,00047.48,W*75 $PGRMA,437,f,2*01 $GPXTE,A,A,,,N*3C $GPBWC,08,,T,,M,,N,*1E $GPRMC,09,A,5137.56,N,00047.48,W,001.7,027.5,010196,,*03 $GPRMB,AV*71 $GPR00,,*45 $GPGLL,5137.56,N,00047.48,W*75 $PGRMA,437,f,2*01 $GPXTE,A,A,,,N*3C $GPBWC,10,,T,,M,,N,*17 $GPRMC,12,A,5137.56,N,00047.48,W,001.8,028.1,010196,,*0D $GPRMB,AV*71 $GPR00,,*45 $GPGLL,5137.56,N,00047.48,W*75 $PGRMA,437,f,2*01 $GPXTE,A,A,,,N*3C $GPBWC,12,,T,,M,,N,*15 Ed Davies.
Re: BBC - Leap second talks are postponed
David Harper wrote: The experiment was abandoned in October 1971, when the clocks were put back to Greenwich Mean Time, Out of historical interest, anybody know if this was true, or were the clocks actually put back to UTC? I.e., when did MSF, etc, switch from GMT to UTC? By the way, this was just before the point when UTC switched from rubber seconds to leap seconds. In October 1971 UTC days were 86 400.002 592 TAI seconds long. This was true until the first of January 1972 when UTC seconds became the same length as TAI ones. It's true that the GMT/BST naming scheme does not conform to the Standard Time/Daylight Time pattern, but GMT is equivalent to Western European Standard Time I've not heard the terms WEST and WEDT used before but assume this is right to +/-0.9 seconds and BST to Western European Daylight Time. Yes, that sounds right, exactly. However, it would be a brave and foolhardy M.P. who proposed in Parliament that the names GMT and BST should be abolished and replaced by WEST/WEDT. That would generate a far greater furore in British politics than any discussion about leap seconds :-) I thought GMT already had been abolished for practical purposes. It's a pity that the name continues to be misused. However, as Rob Seaman has pointed out in a separate thread: If you want to propose an international civil time standard without leap seconds, start by calling it something other than UTC. Leap seconds are intrinsic to the concept of UTC. I agree with most of what Rob says in that message and especially with this. If there's any possibility of the basis of civil time not being one of the UT timescales then it should be given a different name. Getting everybody to change from saying "GMT" to "UTC" to then tell them to change to something else seems like the sort of thing which causes irritation with technical and bureaucratic people. On the other hand, I rather snigger at the reservation of the word "universal" to mean time based on the Earth's rotation. It's all rather parochial but it is the established terminology. Ed.
Re: BBC - Leap second talks are postponed
In message <[EMAIL PROTECTED]>, Tom Van Baak writes: BBC News, 9 November 2005, 08:36 GMT [sic] Poul-Henning Kamp replied: No, GMT is correct, that is the legal time in the UK. But the BBC time signals, etc, are all actually UTC. I doubt anybody at the BBC needs to know what the time is in GMT. GMT is legal time in the UK in the sense that, in the absence of any indication of the use of other time scales, the interpretation of dates and times in legal documents is GMT. All practical applications are UTC so, if it ever really mattered, it would be necessary to convert UTC times to GMT - e.g., to resolve a dispute in court. "GMT" is, unfotunately, widely used to mean the time in Britain during winter. More to the point - it's excellent news that they're delaying for more consensus. Taking a decision either way when there are such obvious disagreements seems like a really bad idea. Ed Davies.
Be thankful for John Flamstead
BBC article, "Leap second proposal sparks row": http://news.bbc.co.uk/1/hi/sci/tech/4420084.stm I found this bit particularly amusing: The decision stemmed from the work 200 years previously of the first English Astronomer Royal, John Flamsteed, who calculated that the Earth rotated on its axis once every 24 hours. It must have been very confusing for people before it was realised that there were 24 hours in a day. You'd have thought somebody would have noticed the pattern before, though. And yes, my inner pedant has to note that it's once and a bit every 24 hours. Ed.
BBC on-line article
The BBC web site has an article about the leap second debate: http://news.bbc.co.uk/1/hi/sci/tech/4271810.stm Ed Davies.
Re: RAS hits the news
I wrote: So, dropping leap seconds from UTC would cause these receivers to, eventually, go back 19 years on cold start? Hardly a major catastrophe but worth noting. Tom Van Baak replied: There are no proposals to "drop leap seconds" as such. The proposal, as I understand it, is/was to hold leap seconds at their current value. Of course - by "drop leap seconds" I meant drop them from the specification so that no further leap seconds would be inserted. The current offset between UTC and TAI (and therefore GPS time) would be maintained. In this case no computer or GPS receiver or cell phone or clock appliance or any man-made timing related intra-planet technology would go forward or back or anything. Observe that nothing will break, for example, if the 12/31/2005 leap second were to not occur. The only problem is that UTC would soon diverge from UT1 beyond 0.9 seconds and so extra-planet devices (e.g., precision telescope systems) would need correction at some point. This introduces a large set of interesting, legitimate, philosophical and financial questions by, especially, astronomers. But either way, nothing with GPS receivers will break. Not immediately. But a GPS receiver which uses the current leap second offset (UTC against GPS time) to help guess which 1024 week period it is in will _eventually_ not work quite right. If no more leap seconds are inserted the UTC-GPS offset will stick at about 13 or 14 seconds or whatever it is now (or will be after the end of this year) which the GPS would associate with the current 1024 week cycle. On a cold start in 2025 it will find that same offset and assume that it's back in 2005 or there abouts. Actually, things could start to go off the rails in about 512 weeks (about 9.8 years). As I said, this is not a big issue at all. In particular most current GPS receivers will probably be dead by then anyway, though one of my GPS receivers in current use is over 12 years old.
Re: RAS hits the news
Hornaday, Tem SPAWAR wrote: ... 3. As has been pointed out, some receivers also implement a clever hack to determine date that looks at UTC Leap Second (LS) value, and chooses a date based on WN, TOW, and LS. That is, the receiver implements a sliding 1024-week window whose limits are determined by the current value of LS. Current date "will" then reside within this 1024-week window. So, dropping leap seconds from UTC would cause these receivers to, eventually, go back 19 years on cold start? Hardly a major catastrophe but worth noting.
Re: Consensus rather than compromise
Ed Davies wrote: : (running to their own little timezone not being good enough), M. Warner Losh wrote: Might I suggest that digs like this make rational discussions difficult? I'm sorry you read that as a dig. That was not what I was intending. All I was trying to say is that if a system is sufficiently isolated that it can't easily be updated with leapsecond information then it probably doesn't matter too much if times _within_ that system are offset from UTC by a second or so. In effect, the uncorrected time used within the system becomes a sort of local timezone - in the same way that GPS time which is UTC from some date but ignoring more recent leap seconds could be thought of as a timezone. Ed Davies.
Re: Consensus rather than compromise
M. Warner Losh wrote: Also, many systems just aren't connected to a public network, or aren't connected to a network at all, but still have a need to have knowledge of leap seconds. Can you give any examples of systems which need to follow UTC to sub-second accuracy (running to their own little time- zone not being good enough), have a clock stable enough to do so and yet are not connected by any mechanism which could potentially provide leap-second information? Presumably there are a few but I find them hard to imagine. Ed Davies
Re: Long term scheduling and bounding DUT1
Warner Losh wrote: One thing I've proposed on other lists is to allow UT1-UTC to get as large as say 5s or 10s. Then predict the number of leap seconds we'll have over the next 10, 20, 50 years (whatever the state of the art is believed to be to keep DUT1 in that new, looser range). We then schedule today that they will happen at these times over the next 10, 20 or 50 years. The earth's natural variation may mean that UT1-UTC is > 1s during these times, but is still bounded because we've added these seconds. Is "bounded" right here? Perhaps "unbounded but probably quite small" would be better. Ed.
Re: decision tree for civil time
Rob Seaman wrote:
This is a first draft of what is intended to be a complete inventory
of options for civil timekeeping.Just compile the options now -
we'll undoubtedly express our opinions about each later.
...
C) Method
1) steps (I'm tired of the word "leap)
a) arbitrary size
b) fixed size
i) second
ii) minute
iii) hour
iv) other
2) rates ("rubber seconds")
3) both
...
Could come under "other" perhaps but millisecond steps are worth
listing explicitly. At least, that's how I assume the epsilon
scheme would be implemented.
Ed.
Re: Precise time over time
Poul-Henning Kamp wrote: In message <[EMAIL PROTECTED]>, Greg Hennessy writes: On Fri, 2005-08-12 at 08:44 +0200, Poul-Henning Kamp wrote: In message <[EMAIL PROTECTED]>, Greg Hennessy writes: Will you support a proposal that keeps leap-second (or -minutes), but mandates that they be determined 40 or 50 years in advance ? Determined to what accuracy? Whatever the prediction is able to nail it to. I realize that this means that the bounds on |UT1-UTC| increases to about a minute, worst case, but already given todays predictive capabilities, I think it will be possible to keep the difference within a handful of seconds. I personally would NOT support such a proposal then. I might be willing to support a proposal that calls for broadcast of the difference of UT1-UTC as well of a long term determination of leap seconds. I took for granted that the UT1-UTC difference needs to be made electronically available. Currently UT1-UTC is made available on the broadcast time signals (WWV, Rugby, etc) to a resolution of 0.1 seconds. The encoding assumes |UT1-UTC| < 0.9 seconds. Anybody have any idea how many systems actually make use of this? How this signal deals with the difference going over 0.9 second is, I think, a relatively minor point but it does need to be considered. Ed Davies.
Re: Rubber seconds
Poul-Henning Kamp wrote: 1. It is agreed that there are applications for which rubber seconds are unsuitable. Yes. 2. Any use of rubber seconds will therefore only be for some limited subset of applications. Yes. 3. There is no way in hell we can prevent applications of the two kinds from interacting. Yes. 4. It follows therefore logically that any kind of rubber seconds will introduce a new interface across which time will have to be translated from rubber to SI seconds. No. Applications using UTS are presumably ones which don't care that much about exact time relative to TAI or whatever so translation is not necessary. E.g., if some application writes logfile timestamps in UTS but some other application reads and interpretes them as UTC it doesn't really matter. Mostly it'd just be a case of comparing the times anyway. Granted, there could be problems with different sources of information (e.g., logfile entries vs filesystem time stamps). 5. You have just introduced yet another place where computers and people can and will get timekeeping wrong. See above. 6. We are trying very hard to avoid interfaces where time can be messed up or confused. But I don't think you can. E.g., consider a computer which has not been able to contact an NTP server for a while so hasn't got an accurate clock. When it contacts an NTP server it's got a choice: jump the clock (potentially non-monotonic) or steer the rate (rubber seconds). Different applications would have different needs. Others would just want to know elapsed times. QED: rubber seconds in any shape or form will only make the problem worse and not better. Remember that UTS is not supposed to be a wonderful solution to everything - just a practical way of improving systems which run software which is not prepared to or doesn't want to deal with leapseconds. In this sense, it'll make the situation better than it is at the moment where different non-leapsecond aware APIs deal with leapseconds in different ways. Please note that I'm not suggesting that rubber seconds are good in all cases: just that there are some circumstances where they are acceptable and, maybe, preferable to having non-monotonic times or times like 14:59:60. There is nothing non-monotonic about it. This depends on the implementation, I think. Are you sure there an no systems which don't just repeat the leapsecond? I thought some Unix implementations do that but I'm not sure. That would be non-montonic: 23:59:58.75 23:59:59.00 23:59:59.25 23:59:59.50 23:59:59.75 23:59:59.00 23:59:59.25 23:59:59.50 23:59:59.75 00:00:00.00 We just need (much!) longer notice about when it happens to handle it properly in computers. Or an adequate way of getting the information to those systems which require it. I wrote a proposal on the subject a while back but dropped it off my website at the end of last year. I've just put it back: http://www.edavies.nildram.co.uk/dns-leapseconds/ And yes, more notice would be a good idea, too. Ed Davies.
Re: Rubber seconds
Poul-Henning Kamp, replying to Markus Kuhn, wrote: Also, your UTS proposal is a total non-starter: Rubber seconds is not a usable solution. I replied: Whether rubber seconds are usable or not depends on what problem you intend them to be a solution to. If you just want a monotonic timestamp stream to be able to give ordered labels to events (e.g., file system transactions) then they are pretty good. Similarly, making sure that scheduled events don't fall between the cracks of clock updates is a lot easier if you steer the clock via rate changes rather than make jumpy phase changes. Poul-Henning Kamp replied, quoting only the first sentence of my first paragraph: Rubber seconds are _never_ usable, just like rubber meters, rubber kilos and rubber unit charges are never usable. Why do you write this when I've just given a examples of cases where rubber seconds are usable? It might help if you could explain what you think is wrong with my examples. Please note that I'm not suggesting that rubber seconds are good in all cases: just that there are some circumstances where they are acceptable and, maybe, preferable to having non-monotonic times or times like 14:59:60. Remember that this is a list for the discussion of the future of leap seconds. Any answer which simply assumes that leap seconds should go away is rather missing the point. Personally, I think that a switch to TAI (or at least frozen UTC) is, on balance, probably a good idea but that before such a decision is made there should be a proper discussion of what the real issues with keeping leap seconds are (and also, of course, what the real issues with discarding them are - though that's not so relevant to rubber seconds). Ed Davies.
Re: Rubber seconds & need for different timescales: was Stupid question from programmer: Why not just eliminate ALL UTC corrections ?
Poul-Henning Kamp wrote: Also, your UTS proposal is a total non-starter: Rubber seconds is not a usable solution. Whether rubber seconds are usable or not depends on what problem you intend them to be a solution to. If you just want a monotonic timestamp stream to be able to give ordered labels to events (e.g., file system transactions) then they are pretty good. Similarly, making sure that scheduled events don't fall between the cracks of clock updates is a lot easier if you steer the clock via rate changes rather than make jumpy phase changes. E.g., the methods you listed for creeping up on a time instant by binary chop work well in these circumstances. Of course, if you need to record intervals accurately then rubber seconds are a disaster. You need to be using a different clock. Similarly, if you need to stay in phase with processes defined in SI seconds then rubber seconds are not good to use. There is no single way of labelling time instants which is good for all applications. This is fundamentally because the rotation of the Earth is variable and unpredictable and because we don't have ubiquitous and instanious access to some standard time. All we can hope for is to have a set of timescales which are related in a way which makes sense for the intended users - including the important characteristic that those users can understand the limitations of the scales they use. Ed Davies.
Re: BBC beeps
"Clive D.W. Feather" wrote on 2005-08-05 07:48 UTC: At the other end of the scale, BBC radio transmits the "Greenwich Time Signal" on many channels on many hours, so the public expects it to be correct. Markus Kuhn replied: Oh, those good old analog broadcast days are soon gone. With the move to MPEG audio compression on many radio and TV broadcast channels, both the transmission latency and its variance have risen to several seconds. Unfortunately, the standards committees defining the DAB and DVB digital audio and video broadcasting standards neglected to define the exact phase offsets to be maintained between the transmitter and the receiver clock. As a result, the BBC beeps can be several seconds off these days and it is not easily possible for the broadcaster to compensate for the transmission delay. I'd expect them to sooner or later give up and remove sub-minute accuracy clock displays (such as the famous beeps) from these broadcasts. A discussion of this a while back on this list caused me to ask a retired BBC Radio (Radio 4, mostly) studio manager about their timing - specifically about whether they ran the studio operations a few seconds ahead of local civil time to allow for digital transmission delay. My recollection of the conversation is that he said that they don't run ahead, they were aware of the problems with the delay of beeps on digital transmissions, that they were pretty unhappy about it and were, at the time he retired, considering suppressing the beeps from the digital signals - no time check being better than a wrong one. They run their schedules pretty accurately - to the second or so. One of the more unusual skills presenters are respected (or not) for (at least in his rather specialised circles) is the ability to smoothly end the programme at exactly the right time even from an ad-lib live discussion. Hence my recent comments about civil vs SI seconds in TV; TV being a better illustration because of the natural importance of stable short period times such as frame rates. Ed Davies.
Re: new beginning
Rob Seaman wrote: ... 3) Clarify the relationship between the civil second and the SI second. It may be too late to define a new unit of duration - whether Essen or Fressen - or perhaps it isn't. In any event, there are 86400 seconds per solar day, and that usage of the word "second" clearly differs from the SI unit which happens to have the same name. What are we going to do about it? (Certainly the ITU proposal does not address such issues.) ... Perhaps it would be a mistake for the relationship between civil and SI seconds to be anything other than identity. There isn't a clear separation between the use of one and the other. Consider, for example, a TV system. The frame rate and so on of the TV signal would, presumably, be defined in SI seconds. On the other hand, the schedule for the day would be in civil seconds. Of course, the schedule doesn't need to be held to the exact second (though it's often done pretty close to that) but somewhere in the chain there would have to be a switch over. Where, exactly? In other words, I'm suggesting that any attempt to "fix" leaps (seconds, minutes, hours or whatever) by use of rate changes in civil time (relative to atomic time) results in a cure which is worse than the disease. Whether or not there are 86400 seconds per solar day is something which should be up for discussion - not taken as a matter of definition. Clearly, there's a use for a "solar second" but perhaps it's even more specialised than a sidereal second. Ed Davies.
Re: Stupid question from programmer: Why not just eliminate ALL UTC corrections ?
Scott Moore wrote: So lets say we get rid of UTC corrections, leap seconds, hours, everything. No corrections, because UTC will be defined as "whatever the freaking planet is doing". If user X is capable if figuring out the current solar/earth time to 10 places, cool. All that matters is that the time reference generators like WWV, and Internet time servers have good to excellent accuracy, I.e., they can calculate solar time from atomic time with enough places to satisfy everyone concerned. What you are failing to realise is that the "time reference generators" you mention serve two purposes: to transmit a reference time (as you mention) but also to act as a standard frequency service. Using UT1 or somesuch (Earth angle time) as you suggest results in variable length seconds. This was what was done prior to 1972, when UTC was introduced to fix this. Ed.
Re: a failure caused by lack of leap seconds
Steve Allen wrote: > ... > There are, also, uncounted documents which assert that leap seconds > may only occur at the end of June or December. Such documents are > provided even from organizations which ought to know that ITU-R TF.460 > permits them to occur at the end of any month. > ... The IERS comes within a hair's breadth of being such an organization because IERS bulletin C can easily give this impression. While this (from Bulletin C 26): # Leap seconds can be introduced in UTC at the end of the months of # December or June, depending on the evolution of UT1-TAI. is strictly true in the sense that leap seconds can be introduced at the ends of December or June as well as other months (it doesn't actually say that leap seconds can *only* occur at the end of December or June) very few people would be pedantic enough not to read it that way. It is so misleading that it really should be fixed. I now realise that when I commented a while ago in this list on the wording of Bulletin C I should have drawn attention to this sentence in combination with the one which I did quote, which was: # NO positive leap second will be introduced at the end of December # 2003. Introducing a negative leap second at the end of December and positive leap seconds at the ends of August and September, with perhaps an extra one on November 5th just for fun, would be quite consistent with the wording, but clearly not with the intent, of this Bulletin. (Yes, I know one on November 5th wouldn't be consistent with TF.460 but it would be consistent with the Bulletin). Ed Davies.
Let's have more leap seconds
Thinking about Steve Allen's post about a problem with the Motorola Oncore GPS receivers caused by the recent lack of leap seconds I began to wonder if we ought not to have a lot more leap seconds. Suppose that instead of leap seconds only being inserted when required to minimize |UT1-UTC| they were inserted whenever possible. That is, whenever they can be inserted without risking |UT1-UTC| > 0.9s. This would mean that nearly 80% of months would have leap seconds. Generally there'd be an alternating sequence of positive and negative leap seconds. This would not eliminate the possibility of a problem like that of the Oncore because there could be a long period with close to 86 400 second days where UT1-UTC happens also to be too close to zero (magnitude less than just over 0.1) to allow a leap second to be inserted. It would also increase the average magnitude of UT1-UTC (from something just over 0.25 to about 0.45) but who actually cares what the average is? You have to plan for the worst case according to the specification (0.9s) anyway - anybody who assumes it'll never go much over 0.5 deserves whatever happens. The advantage of this scheme would be that systems would usually be tested for correct operation over leap seconds early in their life, ideally during testing or commissioning, and anyway when things are still fresh in people's minds. It would be a bit of a nuisance for systems which require manual intervention for leap seconds but at least the operators would get some practice. An example would be the UKIRT in Hawaii which, if I understand the manual properly, can't interpolate Earth orientation over a leap second. A minor problem for an optical telescope in Hawaii but a major one for one on Tenerife. (Actually, I think USAF IR telescopes on Hawaii do operate during the day and therefore potentially over a leap second - the Shuttle Columbia was imaged at, IIRC, about 11 in the morning local time.) It would also ensure that systems work properly when there are multiple leap seconds scheduled and for a variety of signs and magnitudes of UT1-UTC. I know this sounds like a silly idea but I do think it has some merit. Either you can handle leap seconds, in which case extra ones are little trouble, or you can't in which case you need to find out as soon as possible. Essentially, it reduces one of the problems with leap seconds: that they are rare events. Ed Davies.
Re: ITU-R TF.460 past, present, and future
Steve Allen wrote: > ... > Basically, as a result of this case it has been established that the > law in the United States must be in the public domain, and this holds > true even if the law incorporates an external document merely by > reference. So, if NIST tries again to modify the US Code in this > fashion, and they succeed, then the ITU will lose their copyright over > the content of TF.460 within the United States. Any citizen of the US > will not be liable for reproducing it. > ... Well, to be precise: any citizen of the US will not be liable for reproducing it *in the US*. However, I think that by international treaty the US has agreed to protect the copyright of works made in most other countries. Therefore, US law cannot adopt UTC by reference to TF.460. Ed.
Re: more media coverage
Rob Seaman wrote: > One would expect that at least > as many "applications" worldwide depend on time-of-day as depend > on date formats. Sorry, but this one doesn't expect anything of the sort. It seems to me that many more applications are interested in time durations than in the exact orientation of the Earth. Perhaps a way of moving the discussion on would be to make a list of applications requiring accurate Earth orientation information: 1. Pointing telescopes. 2. Pointing satellite dishes. 3. Celestial navigation. 4. Calculating the civil times of sunrise and sunset, lighting up times, etc. Others? Ed Davies.
Re: more media coverage
"Clive D.W. Feather" wrote: > > Steve Allen said: > > CNN is broadcasting the video form of this story today > > > > http://www.cnn.com/2003/WORLD/europe/07/22/time.boulden/index.html > > > > I surmise that Mr. Catchpole was not prepared with the figures. > > He also seems to be unaware of the legal status of GMT in the UK. What the article says is: # But few people officially use GMT anymore. It died in the 1970s, when # governments adopted Coordinated Universal Time, or UTC. I think you are being pretty hard on the article as it is correct that most people don't actually *use* GMT anymore, either officially or otherwise and whether they realise it or not. The UK government adopted UTC in the sense that the NPL (paid for by the government) propogates UTC - even if GMT is still the "default" timescale for legal documents. There could be very unusual cases where the difference between UTC and GMT matters and no timescale has been specified where any UTC or BST timestamps or whatever should (as the law currently stands) be converted to GMT for legal purposes but that's rather different from saying that people actually use GMT. Ed Davies.
Re: DRM broadcast disrupted by leap seconds
Markus Kuhn wrote: > When the scheduled transmission time > arrives for a packet, it is handed with high timing accuracy to the > analog-to-digital converter, I assume you mean digital-to-analog. > ... > [In fact, since short-wave transmitters frequently switch between > programmes at the full hour, in discussions the hope was expressed that > in practice nobody will notice.] > ... Don't they also often transmit the time signal on the hour? Ironic, huh? This also raises the point that because the transmission is delayed a few seconds for buffering there is presumably a need for the studio to work "in the future" by a few seconds if time signals are to be transmitted correctly. > Either having a commonly used standard time without leap seconds (TI), > or having TAI widely supported in clocks and APIs would have solved the > problem. Absolutely - and the second suggested solution doesn't need to take 20 years to be implemented. Ed.
Re: more media coverage
Yesterday, while discussing airliner captain's clocks, I wrote: > These clocks are nominally set to UTC. They are pretty good > stable clocks but one of the things the crew is supposed to do > is check them - against their own watches, presumably. A friend who is a B757/767 captain dropped by for tea just now so I asked him about all this. The airline procedure manuals contain instructions for setting the clocks from broadcast time signals - including frequencies and times when time signals are to be expected. In practice, he doesn't think anybody has ever done this unless somebody was really bored in the cruise. Normally they just check the clocks against their own watches. If they're reasonably close they assumes the aircraft clock is probably more accurate. If not, usually because the aircraft has come out from maintenance which has involved removal of batteries, they (the captain and first officer) cross check their own watches then set from them. To illustrate how unworried about the whole matter they are he told me about a practical joke which has been played at least once. On a long flight, with two crews, while one crew was having a rest the other crew reset all the aircraft clocks out by an hour or so. When the resting crew came back it took them about 10 minutes to figure out what was wrong. One of the joking crew stayed on the flight deck partly to check that nothing serious would happen but mostly to enjoy the puzzlement of the new crew when they realised how far "behind schedule" they were. On a similar topic, Rob Seaman wrote: # Aviation has many operational dependencies on time of day, not # just on international time standards. It may be that many of those # dependencies only care about time of day (the orientation of the # Earth wrt the sun) to a precision of 1 second or 1 minute or 5 # minutes or whatever. They might sometimes need to know if it is day or night. Sunrise and sunset times are published in tables in documents which are updated at least yearly, mostly on a 28 day cycle. Other nominally Earth rotation dependent time constraints like night noise bans will be published in UTC or local time anyway. My 757/767 captain friend couldn't think of any actual Earth rotation dependencies - and he's more aware than most people as to the possible issues as he's also into amateur astronomy. Ed.
Re: more media coverage
I while ago, Steve Allen wrote: > > The Guardian > http://www.guardian.co.uk/uk_news/story/0,3604,985020,00.html I replied: # I thought this was, generally, a quite good article but that the # comments about aircraft navigation system's timescales were a # bit overblown. GPS is just one of the inputs that the navigation # systems use. The main ones are usually the INS, inertial # navigation system, and DME, distance measuring equipment. I'd # have thought that GPS receivers would output UTC and that the # rest of the systems would work with either their own internal # clocks or UTC as required. I'll check this with various people # in the industry (pilots and engineers). Yesterday evening, I talked about this with a British Airways engineer who mainly deals with flight recorders - more the ones they use for looking for odd events and trends in both aircraft and crew performance rather than the "black boxes" for accident investigation. The main time source on airliners is referred to as the "captain's clock". It's just a clock with a user interface as awkward as one of the worst digital watch designs. As well as displaying the time to the crew it also sends it to a lot of the other aircraft systems using an ARINC data bus. Depending on the aircraft fit it may or may not know the date. BA's aircraft all have trend monitoring systems (e.g., for engine performance) so need the versions with the date. Other aircraft (including, I believe, those of most of the major US carriers, at least until very recently) don't have these systems so don't need the version with the date. BA sometimes have problems when the wrong sort of clock is fitted as a replacement on their aircraft - this tends to happen with leased aircraft. In the normal case where the proper clocks are fitted they also have the occasional problem where the date finishes up being set wrongly - presumably at least partly because of the user interface. In these cases it doesn't get noticed as it doesn't really matter until the data for trend monitoring gets processed - when silly results can get produced. Then the engineers have to go and make sure that the aircraft clock's date gets set properly. These clocks are nominally set to UTC. They are pretty good stable clocks but one of the things the crew is supposed to do is check them - against their own watches, presumably. Though they are nominally set to UTC they don't know or care about leap seconds. The Boeing 777s have GPS and the B747-400s are being fitted with it. He wasn't sure if the date/time output from this was/would be used for clock setting. The conclusion is that though, of course, there are lots of things on an aircraft which need their own accurate timing there is no pressing need for accurate synchonisation with global standards and no big issues with multiple different timescales - as far as the aircraft's internal systems are concerned. For position reporting and so on there might, of course, be some issues but since the only timescale actually available in the aircraft is its own best approximation to UTC the only question might be whether this approximation is good enough. This doesn't have anything to do with GPS time or TAI or anything, though. Also, the odd leap second here and there is not likely to make much difference. Ed.
Re: "Universial" Time,"Terrestrial" Time -- time for new terminology?
Markus Kuhn wrote: > A point that was made repeatedly at Torino is that the term "UT" > traditionally meant in astronomy a time scale defined by the Earth's > rotation, and that therefore a leap-second free uniform atomic time > should not be called UTC, even if doing so would of course avoid the > need to change the large number of national regulations that explicitely > refer to "UTC" today. > > I understand that the term "Universal Time" was cooked up in the IAU in > the 1920s, but does anyone know more details about the origin of and > reasons for this curious choice of terminology? > > I always thought it was a rather odd selection of words: > > "Universal Time" is not linked in any way with the "Universe" as such. > It is related to the position of the sun in a coordinate system that is > attached to the crust of this particular piece of molten rock. > Yes, "pre-Copernican" is the expression which occurred to me. UTC tracks the rotation of the Earth to +/-0.9 seconds. This new scale (assuming leap hours were actually implemented) would do so to +/- 3600 seconds, or so. There's a difference in scale but not in principle so the argument to get rid of the name UTC is not iron-clad. It's hard enough to persuade people that GMT is dead without having yet another time scale name to deal with. I think it's better to forget what the letters once stood for and just accept that the name "UTC" means the time scale which is the basis of civil time: the one you add various offsets, in hours and sometimes minutes, to in order to get local civil time. For example, "ISO", though appearing to be an acronym, doesn't actually stand for a sequence of words: http://www.iso.org/iso/en/aboutiso/introduction/index.html Ed.
Re: Leapmilliseconds are not a solution
I wrote: > My humble opinion is that in 1972 leap milliseconds should have > been introduced (i.e., set the UTC day length to an integer number > of milliseconds, ... Markus Kuhn replied: # As I explained here before, this is not feasible. It messes up any form # of standard frequency transmission that is not a multiple of 1000 Hz, # ... Yes, we've discussed this before. As always in this list, the answer would be: use TAI. The real point is that any solution will be an engineering compromise. All we can hope to do is to keep the costs to a minimum. When people know about a problem up-front they can usually work round it fairly cheaply. It's the problems which people don't know about until too late which cause the greatest costs. Therefore, I think the emphasis in any solution should be to put most of the work on those who understand and care about these problems - those responsible for such things as frequency standards. I don't believe that the leap hour solution answers this point at all well - because eventually it'll affect everybody. But then, I don't think anybody on this list has really spoken up in favour of leap hours - or have I missed something? Happy aphelion everybody, Ed.
Re: Bulletin C number 26
Bulletin C number 26 says: > ... > NO positive leap second will be introduced at the end of December 2003. > ... Does anybody else find this wording a bit odd? It says there will be no positive leap second at the end of this year but makes no comment on whether they'll be a negative leap second then, or any leap second at other times. I'd have thought something like: # There will be NO leap seconds introduced strictly before 2004-June-30th. would capture the intended meaning with less room for even a tiny doubt. Ed.
Re: making leap hours workable
Markus Kuhn wrote: > ... because it > seems inconvenient as long as politicians worldwide can't agree on > common dates of switching between summer and winter time. ... Well, would you vote for a politician who would agree to ending summer time on the same day over thw whole world - both northern and southern hemispheres? More seriously, I'm not sure why a common date is required. First there's a discontinuity in TI, say at midnight December 31st/ January 1st, resulting in an instaneous change in the offsets of all the timezones around the world - they remain continuous at this point. Then, at convenient times during the year the timezones adjust so that, by the end of the year, they are back at their original offsets. Obviously it would be nice if they did this together but it's not essential. I guess timezones which don't normally implement daylight saving might choose to change at the same time that neighbours which do change. --- I realise that this is something of a "what if..." conversation by people who are not overly impressed with the ITU proposals but I'd just like to poke in my view that I think this idea of dropping leap seconds in about 20 years and replacing them with leap hours is just about the worst possible "solution": - For the next 20 years we'll be stuck with leap seconds but it'll be even harder than now to get people to take the matter seriously because they'll be going away anyway. - Our generations have dumped enough physical rubbish on the future without leaving this "timebomb" in the paperwork, too. My humble opinion is that in 1972 leap milliseconds should have been introduced (i.e., set the UTC day length to an integer number of milliseconds, e.g, 86 400.002 seconds, announced well in advance like the current leap seconds) instead of leap seconds. 99% of people can safely ignore leap seconds and 99% of those left could ignore leap milliseconds (e.g., users of the currently broadcast DUT1 to 0.1s precision) leaving only a few left to really worry. The only snag I can see with leap milliseconds would be the "glitch" in the time signal as a frequency standard over 00:00:00Z - which it would be easy to cancel out because presumably the UTC LOD would be broadcast, probably in the bit positions currently used for DUT1. The big advantage of leap milliseconds is that they would happen often - not like leap seconds which happen so rarely that they might not appear at all in the development cycle of many systems. However, I think there would be a real outcry if an attempt to change to leap milliseconds were to be made now. We've got leap seconds and will have to live with them for a good few years yet. We might as well concentrate on doing this methodically rather than trying to "fix" the problem by storing up a bigger problem for the future. There is probably no significant difference between a "short term" solution which works for the next 20 years and a long term solution which obviates any supposed need for change. Ed.
Re: Pre-1972 UTC seconds and days
Thanks to Steve Allen, Joseph Myers and Jim Ray for comprehensive answers to my two recent questions. I wrote: > > ... did > > TAI-UTC vary during the course of a single UTC day? Steve Allen replied: > For practical purposes it still does. See > http://www.boulder.nist.gov/timefreq/pubs/bulletin/nistat1.htm Well yes, though this rather depends on your definition of "practical". There is a significant difference between millisecond level trends in the *definition* of UTC relative to TAI and sub-microsecond level wobbles in particular *implementations* of UTC. For many applications the best available approximation to UTC, from the 1PPS output of a GPS receiver, is at the microsecond level anyway. Ed.
Pre-1972 UTC seconds and days
Prior to 1972-01-01 UTC days were not an integer number of SI seconds in length. E.g., in the four years immediately prior to this date: TAI-UTC = 4.213 170 0 + (MJD - 39 126) × 0.002 592s from: http://hpiers.obspm.fr/eop-pc/earthor/utc/TAI-UTC_tab.html This means that a UTC day was roughly two and a half milliseconds longer than 86 400 SI seconds. Here's the question: was a UTC second the same as an SI second so that days were a non-integral number of UTC seconds or was the UTC second slightly longer than the SI second? Putting the same question another way: was the MJD date considered to be an integer or a real day number? I.e., did TAI-UTC vary during the course of a single UTC day? This question is mostly just for curiousity but it is slightly relevant when people define time scales supposedly based on an epoch such as 1970-01-01T00:00:00Z. More on this later. Ed.
Re: more media coverage
Steve Allen wrote: > > The Guardian > http://www.guardian.co.uk/uk_news/story/0,3604,985020,00.html I thought this was, generally, a quite good article but that the comments about aircraft navigation system's timescales were a bit overblown. GPS is just one of the inputs that the navigation systems use. The main ones are usually the INS, inertial navigation system, and DME, distance measuring equipment. I'd have thought that GPS receivers would output UTC and that the rest of the systems would work with either their own internal clocks or UTC as required. I'll check this with various people in the industry (pilots and engineers). Meanwhile, this article also reminded me of a question that has been lurking in my mind for a while. We haven't had a leap second for a while even though: 1. The Earth has already slowed down enough, on average, to need a leap second every year or two. 2. The usual tidal effects, etc, have presumably still been busy slowing it down further. So, something has been speeding the Earth up for a while. As this article says - it's not really known what this effect is. My question: does anybody have a feeling as to whether this effect is likely to "unwind" at some point resulting in a faster than normal string of leap seconds? Could we get to leap seconds more often than once every six months any time soon? Ed.
Re: UK law on GMT vs UTC, was: timestamps on death certificates
Brian Garrett wrote: > I'm still intersted in finding out about UT1 (or UT2) > being the basis of civil time; I thought we in the U.S., atavistic though we > may be about switching to SI units, were at least on track with the rest of > the world by making UTC the legal basis of civil time. There was a British parliamentary bill to switch to UTC (from GMT) as the timescale to be used in the interpretation of legal documents where no timescale is specified. This was in 1997. A Google search for "Coordinated Universal Time Bill" will tell you more. I think the Lords' discussion seemed quite sensible and well informed. E.g., they understood the difference between UTC as implemented by NPL and UTC which is the result of correlating lots of clocks around the world (via TAI, of course). I particularly like this bit of humour from Lord Tanlaw, who introduced the bill: # My Bill may not move the earth, but at least it recognises that the # earth moves. Unfortunately for GMT, its movement has been too # irregular and too unpredictable to remain as a timescale for # electronic timekeeping in this country for greater accuracy to # the nearest second. Basically, the bill got through the House of Lords, received its first reading in the house of Commons but was then dropped, I guess for lack of time. At least it was scheduled for a second reading on 1997-11-28 but deferred due to lack of time to 1998-02-13 but I can't find any further references to it for that or other days. I also rather enjoyed these exchanges from the 1998 debate on Scottish devolution when the Lords were discussing whether setting of "timescales" should be devolved to the Scottish parliament or reserved for Westminster (effects of double summer time being a bit controversial here as what is good for SE England is not so good for NW Scotland, and vice- versa). # The noble Lord said: I suppose that we should introduce this # debate by saying, "Here cometh the time lords". Lady Saltoun of Abernethy quoted an encylopedia extract on definitions of UT, UTC, ET, TDB, and TDT then said: # I expect that most of your Lordships are now quite clear as to # what time scales are but I am afraid I am not very much the # wiser. In any event, I wonder whether there is really any point # in devolving them. It was a long debate, with the house sitting over midnight: # Lord Howie of Troon: I do not want to irritate my noble friend, # but I am under the impression that the state of Arizona has a time # zone which might be called eastern mountain time or some such, # but the Navaho reservation, which consists of something like 20 per # cent. of the top right-hand corner of Arizona has its own time # zone. So it can be done. However, I mention this point only to # confuse the issue! All I am saying is that it can be done--but # it should not be done in this case. # # Lord Sewel: I am glad that the noble Lord agrees with me that # what is good for Arizona is not necessarily good for the United # Kingdom of Great Britain and Northern Ireland. # # Lord Ewing of Kirkford: Before the noble Lord, Lord Mackay, # replies, I do not want to irritate my noble friend either, but # according to the clock it is now Tuesday, 28th July; here in your # Lordships' Chamber it is still Monday, 27th July. How does my # noble friend explain that? # # Lord Sewel: That is a time warp! # # Lord Mackay of Ardbrecknish: The proper answer is that you do # not notice time when you are enjoying yourself. More seriously: 1. At least some of the lawyers have a quite reasonable understanding of the time scale issues - in particular, they know the problems with GMT. 2. The law (1978 Interpretation Act) only sets a default time scale for use when no other is specified. If you want to use TDB in writing your will then that's fine. 3. If the government thought the issue was worth dealing with they already have the outline bill to hand. This is what often happens with private members' bills - they run out of time but act as a template for later government legislation. In fact the bill which, in 1997, knocked the UTC bill out (on hunting wild animals with dogs) is now back under government sponsership. Yes, there may be legal problems with monkeying with UTC but they seem to me not to be a complete showstopper. Ed.
Re: timestamps on death certificates
Markus Kuhn wrote: > ... Anyone who ever attended a birth Haven't we all attended at least one? I don't remember much of mine though Salvador Dali claimed to remember being in the womb.
ADS-B, was: Some personal notes on the Torino meeting
First of all, thanks Markus for your report. One borderline off-topic clarification: > He took the > ADS-B (Automatic Dependent Surveilance Broadcast) system as an example, Use of the word "the" here is a bit of a problem. ADS-B is a generic term, a bit like GNSS vs GPS, Glonass, etc. There are three ADS-B systems which I know of being trialed in various parts of the world. One is UAT, being developed by the US parcel carriers (UPS is the "ring-leader" I think) which works on a discrete frequency (980 MHz, if I recall correctly). Another is an extension of GPS-squitter which puts a GPS position and other information on the end of the normal mode S response from a standard modern aircraft transponder (1060 MHz, again IIRC). This is being pushed by the US FAA. The third is VDL (VHF data link) mode 4 which was being trialed in Europe by the Swedish civil aviation authority, Swedish airlines, Lufthansa, gliders in Sweden, etc. VDL mode 4 has been adopted legally in the Russian federation though I've no idea of the implementation state. Some airliners on long oceanic routes call in their positions automatically via satellite. This also comes under the ADS-B banner and is in pretty widespread use, particularly over the Pacific. Regretably, Eurocontrol is pushing for mode S transponders in all aircraft, rather than ADS-B which is, in my humble opinion, a complete disaster for all of general aviation and the military and anybody else who makes a habit of flying around without full air traffic control but that's a rant for another list, I'm just not sure which :-). Anyway, all I'm trying to say is that any discussion about what "ADS-B" does or doesn't do with time had better be clear about which system they are talking about. Of course, if different systems coexist but choose different time scales it's likely that the areas where they try to interoperate will be where the real leap second problems happen. Ed.
Re: Torino presentation
Ed Davies wrote on 2003-05-27 13:56 UTC: > Slightly more relevantly: I was a bit surprised that you did not > put more emphasis on the need to distinguish the different types > of time scales an application program can ask for from an operating > system, as your ctime library highlights. Markus Kuhn replied: > I had thought about this, but I concluded that this would be out of the > scope of the ITU-R, who are in the business of standardizing time signal > broadcasts, and not operating system APIs. Fair point, but if I might summarise what I think is a slightly generalised version of your argument: 1. There's no single perfect timescale for all application requirement combinations (keeps close to UT1, SI seconds, 86 400 second days, etc) - because some combinations of requirements are contradictory. 2. We need to make up timescales for specific combinations of requirements not catered for by existing timescales (e.g., UTS if you are willing to relax the SI second requirement but don't want to use UT1 for sensible reasons). 3. We have to live with lots of timescales - please fix the radio signals to make this easier. You cover points 2 and 3 well but I think rather assume point 1 which is a pity as you are in a good position to illustrate it. If this point was already well understood then perhaps there wouldn't be the same pressure to "fix" UTC in the forlorn hope of somehow making it perfect. Ed.
Re: civil time and Venezuela
Steve Allen wrote: > > Further evidence that having civil clocks tracking atomic time (or > solar time) may be deemed less relevant than other factors. > What good to go through the havoc of redefining UTC when governments > and agencies will do things like this? > > http://www.cnn.com/2003/TECH/ptech/02/28/offbeat.venezuela.time.reut/index.html I find two sentences in this report really bizarre: > To prevent blackouts, the country slightly lowered the frequency of > the current. Why would a small change in frequency have much effect on the power used? Surely reducing the voltage would have an effect but not reducing the frequency (except maybe marginally). > For common quartz clocks, the slight drop in frequency slows the > vibration of the crystal that regulates time keeping, he said, > adding, "People must be going nuts." Umm, why should the supply frequency affect a crystal oscillator? I think they mean non-quartz clocks.
Epsilon proposal vs integer UTC-TAI
Mark Calabretta wrote: > I note that, as yet, we have not heard a reasoned argument against my > proposal for UTC to measure the true length of day in SI seconds. Personally, I really like this proposal and wish that it had been adopted instead of using leap seconds. The main advantages seem to me to be that "odd" case is available for testing every day and that the adjustment is tiny and can be ignored in even more cases than leap seconds can be ignored. The only problem I can see with it is the one Markus notes: time signals would glitch when used as frequency standards over UTC midnight. Also, admitting that days aren't 86'400 seconds long generalises to other planetary bodies better than some of the bonkers ideas around for Mars - the Red Mars example being mentioned earlier in this discussion. But, would it be practical to change now? For example, is it not likely that there are many existing systems which assume UTC-TAI is an integer? If I read the GPS SPS Signal Specification correctly then GPS can handle non-integer offsets but I bet a lot of other systems can't.
Trivial leap second "problem" example
Markus Kuhn wrote: >... > Who needs to know about a leap second more than half a year in advance > but has no access to a time signal broadcasting service (the better ones > of which all carry leap second announcement information today)? >... Here's an example of a real but trivial nuisance, rather than an actual problem as such, caused by leap seconds. A company which I do work for from time to time manufactures logging devices used primarily in gliding but also in other aviation and sport activities. The device is based around a Hitachi HD6303 processor (like a Motorola 6800) with RAM, a real-time clock, pressure transducer (for altitude measurement) and serial port used for upload and to receive input from a "domestic" GPS receiver. Somewhere around 2000 of the loggers have been sold. It originally was created purely as a barograph (pressure altitude recorder) in late 1980s then extended to record position information from a GPS in 1993. Every so-many seconds (user settable) the device records the pressure altitude and listens for position and other information in NMEA 0183 format from the GPS. If it gets a position it records it with the altitude. The basic timing of the trace recording is done using the logger's own clock. In order to "calibrate" the logger's clock, every half hour it also records the UTC date and time as reported by the GPS receiver. Of course, the UTC date/time output by the GPS receiver is delayed slightly, by nearly a second with modern receivers and by nearly two seconds for older receivers like the Garmin GPS-100 (as verified by comparing the NMEA output with the display of a clock driven by a broadcast time standard). But so is the position information and for gliding competition purposes the exact time of a position is more likely to be important than the exact time of an altitude measurement. Also, the pressure altitude is recorded before the logger starts listening for a position NMEA sentence so tends to be, on average, half a second earlier than transmission time of the corresponding position and therefore pretty close to synchronous with it's validity time. Later, when the trace is uploaded the differences between the GPS derived UTC date/times and the logger's own date/times are calculated and the average is taken across the whole trace. This average is then used to correct the times of all the samples to UTC. If a leap second happened in the middle of the trace then it's effect would be averaged out in this process - not too much of a loss. As a double check, I also put in some code to report a warning if the differences between logger clock time and GPS reported UTC varied too much throughout a trace. The question arises: how much is "too much". Well, early GPS receivers (Garmin GPS-100) only output position information every two seconds so we had to allow for the possibility of some date/time samples "catching" a slightly earlier or later beat from the GPS. Also the clock of the logger might drift slightly - much less than one second in the length of a flight. This implies a tolerance of three seconds. But if a leap second happened there'd be another second to consider, too. Hmm, anything else? Dunno, better make it five seconds then. In other words, consideration of leap seconds makes us reduce the sensitivity of a check for other potential problems (like the logger clock speed being significantly out or somebody trying to fiddle the trace in some way). You might ask, why not take leap seconds into account in doing the calculations after upload? Well, that would be possible but this information is not readily available on the scruffy old DOS PC's typically floating about in gliding club club-houses. We could ask the users to enter the information but it seems like an awful lot of hassle for tiny gain. More significantly, I haven't tested the system when a leap second happens. I did record the output of my Garmin 100 over a leap second a few years ago just to see what happens and could try playing that back into a logger but it doesn't follow that the exact timing of the output from the GPS would be right. In case anybody's interested, the GPS was reporting even or odd numbered seconds before midnight then a few seconds after midnight it switched to reporting the opposite. At least with the epsilon proposal the unusual case would be available once a day for testing - as well as having a tiny enough effect to ignore compared with the inaccuracies of most clocks in widespread use. Ed Davies.
Long live UT1
Ken Pizzini wrote: > Right, but in its way UT1 is "king" because that is the measure of > earth-position time which is used in the definition of our current > time standard, UTC. UT1 might be "king" but TAI is the "parliament" and this is a consitutional monarchy. I guess that makes UTC the government, looking to everybody like it's in charge but actually kicked back and forward between the other two.
Telescope pointing and UTC, was: Re: What I do. What do you do?
Steve Allen wrote: > ... > For more than 20 years the Mt. Hamilton telescopes have been pointed > by a system that runs off a multitasking, 8-bit, 6502 processor. Lick > is currently constructing the replacement for this system and also > contracting with an outside agency to supply the pointing system for a > new telescope. These systems are expected to last for many decades. > Neither of these systems expects UTC - UT1 > 1 second. ... Out of curiousity, where do these systems get UTC from? Broadcasts like WWV or GPS, via NTP or someplace else? I assume there is a local, reasonably accurate, clock which is corrected from the external source. Also, do they actually use UTC as an approximation to UT1 or do they correct UTC to UT1 but just have some built in assumption that the correction will be less than one second? If they make the correction, where do they get UT1 - UTC from? Is it entered manually? Ed Davies.
Re: What I do. What do you do?
Rob Seaman wrote: > Perhaps it would help our discussions to simply describe our professional > (or otherwise) connections to UTC and other precision timing issues. Excellent idea. I'm a freelance programmer based in High Wycombe, England. Over the last few years I've worked on a quite a lot of geographical related software (data preparation for the Ordnance Survey Interactive Atlas of Great Britain CD and AutoCAD based software to help with designing aircraft instrument approach procedures) and also, more relevant to this discussion, data logger devices used for scoring various sports. The first were loggers used to record the output of GPSs for gliding (I fly gliders and aeroplanes in my spare time) which were then adapted for use in motor racing and sailing. Most recently we've done some loggers which read RFID tags attached to motor cyclists for scoring off-road events. More generally, I have a lot of interest in the design of programming languages and standards. A lot of what Ken Pizzini wrote in the first two paragraphs of his posting on this subject also applies to me. I thought of quoting those paragraphs directly but I'll just use one sentence: > I have a > strong appreciation of the value of a good standard, and likewise a > strong disdain for any standard which I can recognize as poorly put > together. For good practical reasons but also as an exercise in standard writing I've been having a go at defining a format for geographical positions in contexts such as XML documents. Have a look at: http://www.edavies.nildram.co.uk/lat-long/index.html While I'm not very serious about it I have a more-than-average interest in amateur astronomy. Two of my friends have reasonable size telescopes (8" and 11") which I go and peer through from time to time. I've been following with interest their experiments with motorizing these and with use of webcams with extended exposure times. I do some satellite watching - it was a mention of the campaign to drop leap seconds in the SeeSat-L list that brought me to this list. Here's the first paragraph of a message I posted to SeeSat-L in July last year: > 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. My general concern is that currently most software neglects leap seconds but that in the future, as systems become more tightly networked, this will not be possible. For example, the aviation industry is moving (slowly, as is understandable) towards a new generation of communication, navigation and surveillance systems which will be much more dependent on GPS and the like. In particular, GPS time will be used for many functions such as allocation of time slots for transmissions on VHF and UHF frequencies. Software will, in many cases, run on standard PCs. (There a radar-like system running on Microsoft Windows systems on trial in Sweden and the FAA has somebody looking into the use of Pocket PCs for in-cockpit displays in light aircraft). GPS is widely used in cars, boats, light aircraft and so on. It's use will become more tightly integrated with other systems. The overall result is that there will not be a simple distinction between "precision" timing applications (which need to know about leapseconds and so on) and "non-precision"/"civil" applications which can ignore them. The two will co-exist on the same machines in many application areas - and often in the hands of users who don't want to have to care about the difference. (I'm using "precision" pretty loosely here - meaning anything that cares about time to an accuracy of better than about one second, never mind the nano second level). If we are to continue with the application of leap seconds to civil time then there is a need for a huge education program (particularly of programmers) and some careful thinking to make sure that "precision" applications can get the information they need while existing naive software doesn't get messed up. My worry is that the long term cost of this effort will be neglected because it is widely distributed and not accounted directly. Ed Davies.
Re: what should a time standard encompass?
On Mon 2003-01-27T18:21:02 +, Ed Davies hath writ: > It can reasonably be argued that GPS should have used TAI but that's > rather beside the point as it would still have had a rather odd and > varying relationship to civil time. Steve Allen replied: # GPS did choose TAI. # For all practical purposes GPS = TAI - 19 s. (GPS = TAI - 19) & (x != x - 19) => (GPS != TAI) # For precise purposes it is important to recognize that GPS time varies # from this -- recently by only plus or minus about 50 ns, but # historically by more than that. # # This error alone taints all of the rest of the arguments in this note. Um, I don't think you've shown that I made an error but, even if I did, I hope most readers would consider each of the other arguments on their own merits or otherwise. Ed Davies.
Re: what should a time standard encompass?
William Thompson wrote: > There's been a lot of talk in this forum about civil time, and what it will be > like millenia from now. I find most of that talk rather silly. What tends to > get ignored is that changes to the UTC time standard will make themselves felt > in the astronomical and astronavigation community not in comfortably far away > millenia, but in mere decades. It will affect not only professional > observatories, but millions of amateurs who don't have the resources that > professionals have access too. As far as astronomers, both amateur and professional, are concerned the sole effect of dropping leapseconds from UTC would be that they'd have to look up the difference between UTC and UT1 every few months even in applications where currently UTC is a good enough approximation to UT1 for practical purposes. I can't imagine there are many systems which directly work off a time signal but don't have software which can be modified easily to apply this offset - even if the offset is just entered manually every few months. If UTC drifts away from UT1 then astronomers can reasonably be assumed to have the understanding and motivation required to deal with the change without significant problems. For amateurs, publishing the current offset once a month in a magazine would be quite sufficient - though most could probably look on a web site (USNO/IERS or whereever). This need for simple action on the part of astronomers has to be set against extra complication in a wide range of computer networks and other systems which, as things currently are, should deal with leap seconds but in many cases don't. Most programmers and users don't know about leap seconds and, frankly, don't care. System designers will either neglect leap seconds causing problems (e.g., GLONASS) or bypass them by creating their own time scales (e.g., GPS). It can reasonably be argued that GPS should have used TAI but that's rather beside the point as it would still have had a rather odd and varying relationship to civil time. Everything would be a lot simpler and more reliable if all systems could work with a single simple "universal" time scale which: 1. Has SI length seconds. 2. Has minutes of 60 seconds, hours of 3'600 seconds and days of 86'400 SI seconds always, not just often enough to lull testers into a false sense of security. 3. Has a straightforward relationship to civil time (i.e., fixed offsets of, usually, multiples of one hour). If the cost of getting this is a trivial inconvenience to astronomers and an adjustment of time zones every few thousand years then I'm all for it. Ed Davies.
Re: what should a time standard encompass?
Ken Pizzini wrote: > For any day of the year one can find some locus of points on the > earth's surface where local-apparent-noon-to-local-apparent-noon will > have a duration of one mean solar day. Aren't local solar days longer than mean solar days everywhere around perihelion? I have to admit I only half understand the equation of time. I'm quite happy with the effect of the eccentricity of the Earth's orbit. The Earth moves quicker at perihelion so has to rotate further to get any particular meridian back facing the sun. What makes my brain hurt is trying to understand the effect of the inclination of the Earth's rotation axis to the ecliptic. As the Earth rotates steadily (at least steadily enough for this discussion if not for more general leapsecond consideration) the plane of a meridian sweeps across the ecliptic at a variable rate but I find it really difficult to visualise the effect. If the Earth's orbit was circular, would all local solar days be the same length or would the inclination still cause variation? In other words, is the second cause of wobbles in the equation of time directly the inclination or is it because the inclination changes the sweep rate of the meridonial plane along the ecliptic and hence changes the effect of the extra rotation required at perihelion (and less than mean rotation required at aphelion, of course)? This is all rather peripheral to leapseconds as such but worth understanding if only to remind ourselves how disconnected all modern time standards are from the apparent motions of the sun. Ed Davies
Re: Draft Questionnaire
Rob Seaman wrote quite a lot I agree with but then: > > Might I also suggest one additional change to this discussion? > Since under this "no new leap second" suggestion (whatever the > details) UTC would stop being Universal in any sense of the word, > could we just agree that instead of modifying UTC, we're proposing > a new time standard, and that this new standard should be called > something else entirely? It would still be "universal" in the sense of being the basis of civil time throughout the world. Leaving out leap seconds doesn't make UTC less universal except in the rather weak sense of nolonger linking it to the universe's rotation around the Earth :-). If anything, dropping leap seconds makes UTC more widely applicable. Will the Peoples Republic of Mars really be pleased to have to adjust its clocks to align with the vagaries of the Earth's rotation? I think it would be a bad idea to introduce a new name. People still use "GMT" rather than "UTC". To try to change to yet another name would only add to the confusion to no benefit.
Re: Draft Questionnaire
[EMAIL PROTECTED] wrote: > if UTC is redefined > so that there are no new leap seconds after N years... I think that the quoted fragment implies, assuming no other unmentioned changes, that it is proposed that after N years: 1. All UTC days will be exactly 86'400 SI seconds in length. 2. UTC will then be a fixed number of seconds offset from TAI. 3. Similarly, GPS time will then be a fixed number of seconds offset from UTC. 4. Civil times around the world will continue to be an exact number of hours (multiples of 3'600 SI seconds) (or, in a few cases, half hours) offset from UTC. 5. Civil times will gradually drift away from their associated local mean times. 6. Eventually civil times will presumably need to be corrected to be closer to local mean time, presumably by changing their offsets from UTC in, one would think, one hour steps much like changes between daylight saving and standard time. In fact, in parts of the world where daylight saving is implemented this can be done by just omitting one change for one year. 7. Astronomers and navigators will have to be really careful about the difference between UTC and UT1 as the difference will soon be significant. Have I understood you correctly or is there another interpretation? I think it's worth being really clear what is being discussed here.
