Re: The real problem with leap seconds
On 2006-01-13, Mark Calabretta wrote: I have two time scales, TAI and UT1, that tick at very slightly different rates. I want to make TAI the basis for civil time keeping but I need to make adjustments occasionally to keep it in step with UT1. How do I do it? The answer provided by CCIR was to represent TAI in a variable-radix notation that matches (or appears to match), to within 0.9s, that of UT1 expressed in the usual calendar/clock format. This is done by varying the radix of the seconds field in a pseudo-sexagesimal clock format from 60 to 61 (or in principle 59) on occasions announced 6 months in advance. So if asked for a definition I would say that UTC (post 1972) is a representation of TAI such that ... (you know the rest). The point is that UTC is simply a representation of TAI. Writing UTC as a real reveals it to be TAI. 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. Hence, when I integrate the ticks of UTC I must get TAI, up to an integration constant. This is correct. The integral of d( UTC ) is TAI (up to an integration constant), but this integral is UTC only where UTC is a continuous function of TAI. Astronomers who write UTC as a real (eg, in JD or MJD notation) want an approximation of UT1 to point their telescopes, they do _not_ want TAI. They use UTC as a timescale whose values are close to UT1, but whose rate nevertheless is d( UTC ) = d( TAI ) and not d( UT1 ). Such a function cannot be continuous (and it cannot be differentiable everywhere). At the latest discontinuity of UTC, it jumped from a little bit after UT1 to a little bit before UT1. Michael Deckers
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.
Report of Leap Second Problem with GPS Data
FYI. -- Richard Langley Professor of Geodesy and Precision Navigation === Richard B. LangleyE-mail: [EMAIL PROTECTED] Geodetic Research Laboratory Web: http://www.unb.ca/GGE/ Dept. of Geodesy and Geomatics EngineeringPhone:+1 506 453-5142 University of New Brunswick Fax: +1 506 453-4943 Fredericton, N.B., Canada E3B 5A3 Fredericton? Where's that? See: http://www.city.fredericton.nb.ca/ === -- Forwarded message -- Date: Fri, 13 Jan 2006 09:59:31 +1100 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [IGSSTATION-760]: DARR and 1Hz data from ARGN ** IGS Station Mail 12 Jan 14:59:42 PST 2006 Message Number 760 ** Author: Michael Moore Geoscience Australia Australian Regional GPS Network Geodetic Operation ADVISORY: High rate data, 1Hz 15 minute files, from the ARGN suffered a software problem due to the recently introduced UTC leap-second. Data from DOY 001 to DOY 009 is 1s off in the timestamps reported n the RINEX files. This problem only applies to the 1Hz 15minute files submitted from the ARGN. The software problem has been fixed, and all files from DOY 010 is reporting the correct time. RINEX headers for DARR from DOY 009, was incorrectly reporting an antenna height of 0.000. The headers have now been fixed to report the correct antenna height of 0.0025, and the data from DOY 009 has been resubmitted with the correct header information. I apologise for any inconvenience this may cause. Regards Mike * Michael Moore Geodetic Operations Geoscience Australia Earth Monitoring Group (GEM) http://www.ga.gov.au/ Telephone: (+61 2) 62499052 Fax: (+61 2) 62499929 Email: [EMAIL PROTECTED] GPO Box 378 Canberra ACT 2601 Australia *
Re: The real problem with leap seconds
On 2006-01-13, Ed Davies wrote: 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? :-) 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? 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? 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? Yes, it is specified in [ITU-R TF.460-6. Annex 3]: The dating of events in the vicinity of a leap-second shall be effected in the manner indicated in the following Figures: Follow some pictures; for a positive leap second, it looks like: event |leap second +-|---+ | | | | | | | | | | | | | 59 60 0 1 | ---30 June, 23h 59m--|--1 July, 0h 0m Designation of the date of the event | | | V 30 June, 23h 59m 60.6s UTC They also say: C Coordinated universal time (UTC) UTC is the time-scale maintained by the BIPM, with assistance from the IERS, which forms the basis of a coordinated dissemination of standard frequencies and time signals. It corresponds exactly in rate with TAI but differs from it by an integer number of seconds. The UTC scale is adjusted by the insertion or deletion of seconds (positive or negative leapseconds) to ensure approximate agreement with UT1. E DTAI The value of the difference TAI � UTC, as disseminated with time signals, shall be denoted DTAI. DTAI = TAI - UTC may be regarded as a correction to be added to UTC to obtain TAI. The TAI - UTC values are published in the BIPM Circular T. The IERS should announce the value of DTAI in integer multiples of one second in the same announcement as the introduction of a leap-second (see � D.2). HTH Michael Deckers
Problems with GLONASS Raw Receiver Data at Start of New Year
The International GNSS Service (IGS) includes a sub-network of continuously operating GLONASS monitor stations (about 50) including one at the University of New Brunswick (UNB1). At UNB1 we lost C1 (coarse code on L1 frequencies), P1 (precision code on L1), and P2 (precision code on L2) observations on the 5 GLONASS satellites we were tracking at 00:01:30 GPS Time on 1 January 2006 along with phase jumps in L1 (carrier phase on L1) and L2 (carrier phase on L2). Code measurements were back at 00:04:00. I have just learned from one of the IGS analysis centres that all January 1 IGS GLONASS observation files that they checked show a similar problem. -- Richard Langley Professor of Geodesy and Precision Navigation === Richard B. LangleyE-mail: [EMAIL PROTECTED] Geodetic Research Laboratory Web: http://www.unb.ca/GGE/ Dept. of Geodesy and Geomatics EngineeringPhone:+1 506 453-5142 University of New Brunswick Fax: +1 506 453-4943 Fredericton, N.B., Canada E3B 5A3 Fredericton? Where's that? See: http://www.city.fredericton.nb.ca/ ===
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
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.
Analog clocks and leap seconds
Michael Sokolov writes: I cannot make the beautiful analog clock on the tower show 23:59:60. But it's trivial to make it occasionally take 1.1 SI seconds instead of 1 SI second to turn its hands by 1 civil second. Yes, this is one of the awkward features of a leap second (positive leap second, at least). In practice few clocks with analog displays are accurate enough to even worry about leap seconds. But if you were to design an analog clock that was somehow leap second compatible here is my list of possible implementations: - You can have it run UT1 instead of UTC. - For extra credit, you can have it run sidereal. (http://www.bmumford.com/clocks/sidereal/index.html) - You can pause at :59 or :00 for a second. Or pause halfway in between. - You can slow down a bit sometime before the leap second and resume normal speed sometime after the leap second such that one second is wasted. Even 5 or 15 seconds before and after would be sufficient that no one would notice the rate change. - You can slow it down to exactly 1/2 speed between :59 and :00. This, in my opinion, would be the most visually pleasing. As of last week, photos of digital 23:59:60 displays are now common. But an analog hand slowing down half speed between 59 and 00 would be quite unique. Similarly use 2x speed for a negative leap second, should one to ever occur. - You could wait for the second hand to hit :00 and then go backwards for 1/2 second, then forwards for 1/2 second. Kind of weird, but it would work. - You can design it with 61 seconds around the circle and jump over number 60 (go from 59 to 00) every minute except for when a positive leap second occurs. Also kind of weird, but the further into the future the more it would be appreciated. /tvb http://www.LeapSecond.com
Re: The real problem with leap seconds
I'm glad to see such active traffic on the list - particularly discussions such as this that are wrestling with fundamental concepts. On 2006-01-13, Mark Calabretta wrote: The point is that UTC is simply a representation of TAI. On Jan 13, 2006, at 4:17 AM, Michael Deckers wrote: I believe I'm now grasping what you mean: Have spent many hours wrestling with standards documents written by M. Calabretta. The key to understanding what they mean is to carefully read what is on the page. Simply a representation is not an editorial comment like, say, just a representation might be taken to be. Representations are important, too. It is - simply - not accurate to suggest that UTC is discontinuous at a leap second. DST is indeed discontinuous twice a year, but the underlying standard time never is. Astronomers who write UTC as a real (eg, in JD or MJD notation) want an approximation of UT1 to point their telescopes, they do _not_ want TAI. Astronomers want various flavors of time for various purposes. It is indeed exceptionally useful to be able to rely on simple closed form calculations relating various quantities to universal time, where UTC is often a sufficiently accurate approximation. It happens that we also use TAI and other interval time scales for many things. And it turns out that our images and other data products often benefit from the use of civil time stamps for which good old reliably continuous UTC serves admirably. Ultimately it is the risk to this last category of use cases that concerns me most about the notion of leap hours. That said, I suspect M. Deckers and M. Calabretta could productively collaborate on a document synthesizing the fundamental issues into a common vision. Or perhaps somebody is aware of such a document that already exists? Rob
Re: The real problem with leap seconds
On Jan 13, 2006, at 8:05 AM, Ed Davies wrote: 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? And we're back to the point in question. The precise issue is the definition of the concept of a day. A leap second itself is a clearly defined moment in time.
Re: The real problem with leap seconds
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. I'm not the expert, but I just read through http://en.wikipedia.org/wiki/Julian_day and from what I learned there the answer appears to be that MJD can be either MJD(UT) or MJD(TT), and leap seconds are not involved. So MJD 27123.5 means 12:00:00. on day 27123. MJD(UT) 27123.5 means UT 12:00:00.0 on day 27123. MJD(TT) 27123.5 means TT 12:00:00.0 on day 27123. UTC is an approximation of UT, perhaps the poorest one in the family of UT time scales. If you care about what time it is UT to better than one second, then UTC is probably not the right time scale for you to be using (at least not directly). If a fuzz of +/- 1 second doesn't bother you, then you can pretend that UTC is UT, and things are easier. For the time scale experts on this list, did I get that right? -Tim Shepard [EMAIL PROTECTED]
Re: Analog clocks and leap seconds
Tom Van Baak [EMAIL PROTECTED] wrote on Fri, 13 Jan 2006 at 07:31:50 -0800 in [EMAIL PROTECTED]: But if you were to design an analog clock that was somehow leap second compatible here is my list of possible implementations: ... Please consider a clock with a leap second hand that simply goes around once (in either direction, as appropriate) in the event of a leap second. [EMAIL PROTECTED] John Hawkinson
Re: The real problem with leap seconds
On 2006-01-13, Ed Davies wrote: Michael Deckers wrote: . 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? 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. Right, UTC timestamps are ambiguous (in the sense that the corresponding TAI value is not known) in the vicinity of positive leap seconds, and the notation with a second field = 60 s is one (elegant) way to disambiguate. Another way to disambiguate is to record the value of DTAI together with a UTC (or TAI) timestamp. Such a method is standardised in ISO 8601 for denoting offsets from UTC, but only with minute resolution. I seem to remember that Clive Feather once proposed this for an extension to the C programming language. If you only need an approximation to UT1, however, there is no need to disambiguate, nor is it relevant which value of DTAI is applied during the leap second. Thanks for your patience. Michael
Re: The real problem with leap seconds
From: Ed Davies [EMAIL PROTECTED] 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. Has anybody compiled a canonical list of the standards in this area? This is the first, I think I've seen ISO 8601 mentioned. TF.460 doesn't talk about days at all, really, or MJD. It doesn't talk about rendering a time a floating point number, only as the traditional sexagesimal fractional time, with the 'execption' during the positive leap second. If we explore the orgins of the time 12:34:56 (just after noon) we note that it is in the 13th 1/24th division of a day (since the 0th (aka 12) hour is first), the 35th 1/60th division of the 1/24th division (since the first one is 0) and the 56th 1/60th division of the 1/60th division of the 1/24th division a day. Labeling the positive leap second as 23:59:60 leads to some trouble if we try to work backwards through the above derivation. It creates an exception to the nice, orderly rules of time. But I'm digressing... The ITU-R TF.460 states: 2.2 A positive leap-second begins at 23h 59m 60s and ends at 0h 0m 0s of the first day of the following month. In the case of a negative leap-second, 23h 59m 58s will be followed one second later by 0h 0m 0s of the first day of the following month (see Annex III). 2.3 The IERS should decide upon and announce the introduction of a leap-second, such an announcement to be made at least eight weeks in advance. In Annex III, it talks about the dating of events during the positive leap second. If something were to happen .6s into that second, it would be denoted (assuming a june leap) as: 30 June, 23h 59m 60.6s UTC (the document has h, m and s superscripted, and the European (?) style centered decimal point) Warner
Re: The real problem with leap seconds
I don't know about a canonical list, but one standard document that is used within NASA is CCSDS 301.0-B-3, which is available from the Consultative Committee on Space Data Systems website at http://public.ccsds.org/publications/BlueBooks.aspx This standard references ISO-8601, and is partially based on it. Bill Thompson Warner Losh wrote: From: Ed Davies [EMAIL PROTECTED] 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. Has anybody compiled a canonical list of the standards in this area? This is the first, I think I've seen ISO 8601 mentioned. TF.460 doesn't talk about days at all, really, or MJD. It doesn't talk about rendering a time a floating point number, only as the traditional sexagesimal fractional time, with the 'execption' during the positive leap second. If we explore the orgins of the time 12:34:56 (just after noon) we note that it is in the 13th 1/24th division of a day (since the 0th (aka 12) hour is first), the 35th 1/60th division of the 1/24th division (since the first one is 0) and the 56th 1/60th division of the 1/60th division of the 1/24th division a day. Labeling the positive leap second as 23:59:60 leads to some trouble if we try to work backwards through the above derivation. It creates an exception to the nice, orderly rules of time. But I'm digressing... The ITU-R TF.460 states: 2.2 A positive leap-second begins at 23h 59m 60s and ends at 0h 0m 0s of the first day of the following month. In the case of a negative leap-second, 23h 59m 58s will be followed one second later by 0h 0m 0s of the first day of the following month (see Annex III). 2.3 The IERS should decide upon and announce the introduction of a leap-second, such an announcement to be made at least eight weeks in advance. In Annex III, it talks about the dating of events during the positive leap second. If something were to happen .6s into that second, it would be denoted (assuming a june leap) as: 30 June, 23h 59m 60.6s UTC (the document has h, m and s superscripted, and the European (?) style centered decimal point) Warner -- William Thompson NASA Goddard Space Flight Center Code 612.1 Greenbelt, MD 20771 USA 301-286-2040 [EMAIL PROTECTED]
Re: Monsters from the id
It should be clear that the gaps and repeats are fictitious, especially if you think of AEST and AEDT as existing beyond the times when they are in legal use. Putting it in practical terms, suppose I have a traffic accident at 0230 on 2006/04/02, what time will the police officer write in his report? For most times of the year he can omit the timezone spec because there is no legal ambiguity, but to do so for this specific hour would be insufficient, he must specify AEDT or AEST. There are two instances of 0230 but only one 0230 EST and one 0230 EDT. So that could take care of the ambiguity, if the officer were clever. Or he could use UTC/GMT/Zulu, if the office had a military background. Or, how about this for a laugh... Suppose DST were implemented with +/- leap hours. Consider if the DST switch were made around midnight instead of 2 AM. Then the Spring DST change would jump from 22:59 to 00:00 skipping the 60 minutes labeled 23:00 to 23:59. The Fall DST would be implemented after 23:59 where and extra 60 minutes labeled 24:00 to 24:59 would be added. That takes care of your EST/EDT ambiguity... /tvb http://www.LeapHour.com
Time standards: RFC3339 and ISO 8601, NTP
On Fri, Jan 13, 2006 at 11:32:36AM -0700, Warner Losh wrote: Has anybody compiled a canonical list of the standards in this area? This is the first, I think I've seen ISO 8601 mentioned. As usual, the IETF does a much better job than the ITU of making this stuff available to the general public. See RFC 3339 Date and Time on the Internet: Timestamps http://www.potaroo.net/ietf/idref/rfc3339/ This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. Written via an open process; free for all to read, copy, distribute, implement, or be involved in improvements to; with a complete ABNF syntax specification; compatible with ISO 8601 but without a sufeit of unnecessary alternative formats like ISO 8601. Includes a short section on Leap Seconds, lots of info on time zones, etc. LEAPSECS members Markus Kuhn and myself contributed suggestions to it. And as I noted earlier, the IETF ntp working group is working on updating the NTP standard (RFC1305 on NTP version 3, RFC2030 on SNTP version 4), again in a relatively refreshing and open manner: http://ietf.org/html.charters/ntp-charter.html http://www.potaroo.net/ietf/idref/rfc1305/ Join us and get a standard TAI spec for NTP! Cheers, Neal McBurnett http://bcn.boulder.co.us/~neal/ Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60
