Re: The real problem with leap seconds
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. Please don't come back until you have understood and accepted that this is not the case. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
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
In message: [EMAIL PROTECTED] Francois Meyer [EMAIL PROTECTED] writes: : On Mon, 16 Jan 2006, Mark Calabretta wrote: : : On Fri 2006/01/13 11:17:52 -, Michael Deckers wrote : in a message to: LEAPSECS@ROM.USNO.NAVY.MIL : : 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. : : You're still not getting the point that UTC is just a representation : of TAI. : : Maybe it should be, but this is far from being : obvious from its current definition. : : The actual situation corresponds to : : : 1. UTC and TAI share the same rate, the same :origin, the same second. And therefore : : : UTC - TAI = 0 The history of UTC and TAI is complicated and tricky. You can only say that on Jan 1, 1972, the TAI - UTC offset was fixed to be 10s. UTC and TAI prior to 1972 did not evolve at the same rate. The UTC seconds differed in length from the SI seconds. I'll ignore the nomenclature differences over time as well. : 2. UTC only differs from TAI by its definitions of :the minute, hour and day. This is not true prior to 1972. There were a number of frequency offsets in UTC that weren't present in TAI. Some leap second charts have these included in them. : 4. the UTC minute is defined to ensure that dhms :expressions of UTC match UT1 at .9 s; it can be :either 59, 60 or 61 SI seconds long. This :definition of the minute is realized :by (positive or negative) leap seconds and :ensures that the mean UTC day is the mean solar :day in the long term. The UTC hour has 60 UTC :minutes, the UTC day has 24 UTC hours. Again, post 1972... I'm not sure what I think of this definition. : From that point of view, the sentence from the ITU460-6 : : : [UTC] ...differs from it [TAI] from an integer of seconds : : should read : : : representations of UTC involving minutes, hours, : days differ from equivalent representations of TAI : by an integral number of seconds After 1972, and ignoring minor variations in the realization of UTC and TAI in any given location, this is basically true. The only ideal difference between TAI(ideal) and UTC(ideal) is in the labeling of the pulses that both time scales have experienced. If one were to treat them both as fixed radix, you get the difference of 33s. Viewed topologically as a 1-1 mapping, one could easily define subtraction so that the difference is zero since UTC has a variable radix... To further complicate things, TAI isn't created in realtime, but is a paper clock that's steered to the correct time of the clocks that feed it data. There are clocks that are steered to this paper clock, but it is all done by hand (if the various web pages I've read are still accurate). Different facilities realization of the TAI and UTC time scales may differ by several nanoseconds (or more depending on a lot of factors). However, leaving aside those complications... Given that UTC is a variable radix notation for labeling the pulses that have elapsed since the epoch. TAI is a fixed radix notation for labeling pulses that have elapsed since the epoch. Warner
Re: The real problem with leap seconds
On 2006-01-18, Steve Allen wrote: Now I am confused. By my reading of the documents, ITU-R did not define DTAI until the most recent revision of TF.460 in 2002. DUT1 had been defined since very early on. You are right, the name DTAI has apparently been introduced in 2002. It also appears in [ITU-R TF536.2 2003] and [ITU-R TF686.2 2002]. It is defined in these documents as the values of TAI - UTC and is described as the contribution of the IERS to the determination of UTC. Such values of TAI - UTC are published back to 1972 (step function) and even to 1961 (piecewise linear function). Since I wanted to describe how I understood Mark Calabretta's description of UTC as essentially the same as TAI except for the variable radix notation for the (whole) second field in the time of day values, I took DTAI as a convenient abbreviation of TAI - ( UTC value when interpreted with a fixed radix for the second field ) I avoided writing UTC for TAI - DTAI because this would contradict the assumption that UTC is just TAI plus additional information. Hope that clarifies things a bit. Michael Deckers
Re: The real problem with leap seconds
On Wed 2006/01/18 08:17:54 -, Francois Meyer wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL Maybe it should be, but this is far from being obvious from its current definition. I agree that the current definitions leave a lot to be desired in terms of clarity and rigour - an uncharitable person might even describe the extract of ITU-R TF.460-6 cited the other day by Michael Deckers as inconsistent. However, you have to consider how UTC is actually used in practice and this is what my comments are based on. 1. UTC and TAI share the same rate, the same origin, the same second. And therefore : UTC - TAI = 0 They both count SI seconds but the question of the origin is a bit muddy. You could argue that there is a fixed 10s offset between UTC and TAI because UTC post-1972 (everything I've said about UTC only applies post-1972) started with 10 leap seconds, and before 1972 UTC wasn't simply a representation of TAI. There's no simple way of fudging radixes that I can think of to make them match up, but if this worries you then simply think in terms of proleptic UTC (post-1972), see http://en.wikipedia.org/wiki/Proleptic. However, this is not important and really only confuses things further. (It's why I couched the original example as a graph of a person's age vs UTC rather that TAI vs UTC.) 2. UTC only differs from TAI by its definitions of the minute, hour and day. 3. the TAI day, hour, minute are the SI day, hour, minute of 86400,3600,60 SI seconds. 4. the UTC minute is defined to ensure that dhms expressions of UTC match UT1 at .9 s; it can be either 59, 60 or 61 SI seconds long. This definition of the minute is realized by (positive or negative) leap seconds and ensures that the mean UTC day is the mean solar day in the long term. The UTC hour has 60 UTC minutes, the UTC day has 24 UTC hours. OK, but using the word definition doesn't seem quite right, I'd couch it in terms based on counting seconds. If you consulted the wikipedia entry for Factoradic that I referenced the other day you will see that each digit in the factoradic representation of a number has a subscript indicating its (fixed) radix. The fields (not the digits!) of a UTC representation should have something similar (likewise calendar dates written as 2006/01/19), except that for the seconds field (and the day field) the radix would be variable and there's no simple way to write it, so people assume it's 60 which is what you do anyway if you want your approximation of UT1. From that point of view, the sentence from the ITU460-6 : [UTC] ...differs from it [TAI] from an integer of seconds should read : representations of UTC involving minutes, hours, days differ from equivalent representations of TAI by an integral number of seconds I agree that the ITU-R TF.460.6 text needs fixing, but I would argue for a stronger statement emphasising that a UTC representation (of TAI) has two interpretions, one giving TAI (exact) and the other UT1 (approx), the latter being offset from TAI by an integral number of seconds. Mark Calabretta ATNF
Re: The real problem with leap seconds
In message: [EMAIL PROTECTED] Mark Calabretta [EMAIL PROTECTED] writes: : On Wed 2006/01/18 08:17:54 -, Francois Meyer wrote : in a message to: LEAPSECS@ROM.USNO.NAVY.MIL : : Maybe it should be, but this is far from being : obvious from its current definition. : : I agree that the current definitions leave a lot to be desired in terms : of clarity and rigour - an uncharitable person might even describe the : extract of ITU-R TF.460-6 cited the other day by Michael Deckers as : inconsistent. However, you have to consider how UTC is actually used in : practice and this is what my comments are based on. : : 1. UTC and TAI share the same rate, the same :origin, the same second. And therefore : : : UTC - TAI = 0 : : They both count SI seconds but the question of the origin is a bit : muddy. : : You could argue that there is a fixed 10s offset between UTC and TAI : because UTC post-1972 (everything I've said about UTC only applies : post-1972) started with 10 leap seconds, and before 1972 UTC wasn't : simply a representation of TAI. There's no simple way of fudging : radixes that I can think of to make them match up, but if this worries : you then simply think in terms of proleptic UTC (post-1972), : see http://en.wikipedia.org/wiki/Proleptic. UTC (and its predecessors) prior to 1972 did not tick off in SI seconds. It used a fixed radix like TAI currently does. The amount of time in UTC seconds varied a little. Here's the table from ftp://maia.usno.navy.mil/ser7/tai-utc.dat 1961 JAN 1 =JD 2437300.5 TAI-UTC= 1.4228180 S + (MJD - 37300.) X 0.001296 S 1961 AUG 1 =JD 2437512.5 TAI-UTC= 1.3728180 S + (MJD - 37300.) X 0.001296 S 1962 JAN 1 =JD 2437665.5 TAI-UTC= 1.8458580 S + (MJD - 37665.) X 0.0011232S 1963 NOV 1 =JD 2438334.5 TAI-UTC= 1.9458580 S + (MJD - 37665.) X 0.0011232S 1964 JAN 1 =JD 2438395.5 TAI-UTC= 3.2401300 S + (MJD - 38761.) X 0.001296 S 1964 APR 1 =JD 2438486.5 TAI-UTC= 3.3401300 S + (MJD - 38761.) X 0.001296 S 1964 SEP 1 =JD 2438639.5 TAI-UTC= 3.4401300 S + (MJD - 38761.) X 0.001296 S 1965 JAN 1 =JD 2438761.5 TAI-UTC= 3.5401300 S + (MJD - 38761.) X 0.001296 S 1965 MAR 1 =JD 2438820.5 TAI-UTC= 3.6401300 S + (MJD - 38761.) X 0.001296 S 1965 JUL 1 =JD 2438942.5 TAI-UTC= 3.7401300 S + (MJD - 38761.) X 0.001296 S 1965 SEP 1 =JD 2439004.5 TAI-UTC= 3.8401300 S + (MJD - 38761.) X 0.001296 S 1966 JAN 1 =JD 2439126.5 TAI-UTC= 4.3131700 S + (MJD - 39126.) X 0.002592 S 1968 FEB 1 =JD 2439887.5 TAI-UTC= 4.2131700 S + (MJD - 39126.) X 0.002592 S 1972 JAN 1 =JD 2441317.5 TAI-UTC= 10.0 S + (MJD - 41317.) X 0.0 S 1972 JUL 1 =JD 2441499.5 TAI-UTC= 11.0 S + (MJD - 41317.) X 0.0 S 1973 JAN 1 =JD 2441683.5 TAI-UTC= 12.0 S + (MJD - 41317.) X 0.0 S 1974 JAN 1 =JD 2442048.5 TAI-UTC= 13.0 S + (MJD - 41317.) X 0.0 S 1975 JAN 1 =JD 2442413.5 TAI-UTC= 14.0 S + (MJD - 41317.) X 0.0 S 1976 JAN 1 =JD 2442778.5 TAI-UTC= 15.0 S + (MJD - 41317.) X 0.0 S 1977 JAN 1 =JD 2443144.5 TAI-UTC= 16.0 S + (MJD - 41317.) X 0.0 S 1978 JAN 1 =JD 2443509.5 TAI-UTC= 17.0 S + (MJD - 41317.) X 0.0 S 1979 JAN 1 =JD 2443874.5 TAI-UTC= 18.0 S + (MJD - 41317.) X 0.0 S 1980 JAN 1 =JD 2444239.5 TAI-UTC= 19.0 S + (MJD - 41317.) X 0.0 S 1981 JUL 1 =JD 2444786.5 TAI-UTC= 20.0 S + (MJD - 41317.) X 0.0 S 1982 JUL 1 =JD 2445151.5 TAI-UTC= 21.0 S + (MJD - 41317.) X 0.0 S 1983 JUL 1 =JD 2445516.5 TAI-UTC= 22.0 S + (MJD - 41317.) X 0.0 S 1985 JUL 1 =JD 2446247.5 TAI-UTC= 23.0 S + (MJD - 41317.) X 0.0 S 1988 JAN 1 =JD 2447161.5 TAI-UTC= 24.0 S + (MJD - 41317.) X 0.0 S 1990 JAN 1 =JD 2447892.5 TAI-UTC= 25.0 S + (MJD - 41317.) X 0.0 S 1991 JAN 1 =JD 2448257.5 TAI-UTC= 26.0 S + (MJD - 41317.) X 0.0 S 1992 JUL 1 =JD 2448804.5 TAI-UTC= 27.0 S + (MJD - 41317.) X 0.0 S 1993 JUL 1 =JD 2449169.5 TAI-UTC= 28.0 S + (MJD - 41317.) X 0.0 S 1994 JUL 1 =JD 2449534.5 TAI-UTC= 29.0 S + (MJD - 41317.) X 0.0 S 1996 JAN 1 =JD 2450083.5 TAI-UTC= 30.0 S + (MJD - 41317.) X 0.0 S 1997 JUL 1 =JD 2450630.5 TAI-UTC= 31.0 S + (MJD - 41317.) X 0.0 S 1999 JAN 1 =JD 2451179.5 TAI-UTC= 32.0 S + (MJD - 41317.) X 0.0 S 2006 JAN 1 =JD 2453736.5 TAI-UTC= 33.0 S + (MJD - 41317.) X 0.0 S (or the yet to be updated http://www.iers.org/MainDisp.csl?pid=95-106) Here's slides from a presentation that is actually fairly well balanced: http://www.ien.it/luc/cesio/itu/mc_carthy.pdf It has history there as well. There's a nice graph of the above on page 20. http://www.ucolick.org/~sla/leapsecs/timescales.html also contains a nice summary of UTC which is too long to include here but in outline form is: UTC during 1960 UTC from 1961 through 1971 UTC in 1963 UTC in 1965 UTC
Re: The real problem with leap seconds
Mark Calabretta wrote: You're still not getting the point that UTC is just a representation of TAI. OK, let me try again. UTC (since 1972) is a disseminated timescale that is equal to TAI except for additional date and time codes transmitted with the signal. These codes indicate the values of TAI - DTAI for each full minute of TAI - DTAI. In a reading of UTC, (the most recent values of) these date and time codes can be taken as is so as to yield a reading that approximates UT1. The codes may also be used to derive the value of DTAI (from a table of leap seconds since 1972), and thus, to yield a reading of TAI. When a timestamp is characterised as UTC (rather than TAI), then the first type of reading is implied. In order to ensure a unique derivation of TAI from a recorded reading of UTC in the vicinity of a positive leap second (where DTAI jumps up by 1 s and the value of TAI for a given value of TAI - DTAI is not unique), the UTC reading that corresponds to the earlier TAI value shall be recorded with a second field = 60 s, and the other UTC reading, with a second field 60 s. Michael Deckers (still trying to understand the topology you referred to)
Re: The real problem with leap seconds
On Mon 2006/01/16 12:11:04 -, Michael Deckers wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL UTC (since 1972) is a disseminated timescale that is equal to TAI except for additional date and time codes transmitted with the signal. These codes indicate the values of TAI - DTAI for each full minute of TAI - DTAI. In a reading of UTC, (the most recent values of) these date and time codes can be taken as is so as to yield a reading that approximates UT1. The codes may also be used to derive the value of DTAI (from a table of leap seconds since 1972), and thus, to yield a reading of TAI. When a timestamp is characterised as UTC (rather than TAI), then the first type of reading is implied. In order to ensure a unique derivation of TAI from a recorded reading of UTC in the vicinity of a positive leap second (where DTAI jumps up by 1 s and the value of TAI for a given value of TAI - DTAI is not unique), the UTC reading that corresponds to the earlier TAI value shall be recorded with a second field = 60 s, and the other UTC reading, with a second field 60 s. Michael Deckers (still trying to understand the topology you referred to) I think we are basically on the same wavelength, though I would turn some of your sentences around. The way UTC is disseminated is not directly relevant to the discussion, and I don't think I said anything about topology. A better way to think about it would be from the combinatorics point of view. Enumerative combinatorics is basically concerned with counting things, usually counting them two ways and drawing conclusions from that. Use of mixed-radix numbers is one of the strategies used in combinatorics, e.g. see http://en.wikipedia.org/wiki/Factoradic. The representation of UTC as a variable-mixed-radix number is a clever way (possibly too clever) of counting seconds of TAI in a way that allows interpretation as either TAI or, approximately, UT1. The UT1 (or time_t) interpretation is obtained by treating UTC's representation (label, notation) at face value, as though it was an ordinary sexagesimal number. UT1 so derived does have a discontinuity when leap seconds are inserted and presumably this is what leads people to say, misleadingly, that UTC itself is discontinuous. On the other hand, TAI is recovered when the variable radix of the seconds field is taken into account. However, since they occur irregularly, this interpretation requires a table containing the full history of changes in the radix. Alternately, the cumulative effect of the table for epochs since the last leap second is conveniently summarized in a number that we call DTAI, usually referred to as TAI-UTC, where UTC here is understood to be the usual mixed-but- fixed-radix sexagesimal representation. So there is plenty of scope for confusion. However, think back to the graph of age vs UTC that I described at the start of this discussion and particularly that each instant of the continuous time axis has a unique UTC representation. Mark Calabretta ATNF
Re: The real problem with leap seconds
From: Mark Calabretta [EMAIL PROTECTED] Subject: Re: [LEAPSECS] The real problem with leap seconds Date: Tue, 17 Jan 2006 11:15:09 +1100 On Fri 2006/01/13 12:32:27 +1100, Mark Calabretta wrote in a message to: Leap Seconds Issues LEAPSECS@ROM.USNO.NAVY.MIL So if asked for a definition I would say that UTC (post 1972) is a representation of TAI such that ... (you know the rest). .. and I should have said that prior to 1972, when UTC had rubber seconds, it was not a representation of TAI but something else again. Yes. TAI was recoverable from the UTC that existed prior to 1972, but the math wasn't a simple addition... Warner
Re: The real problem with leap seconds
On Fri 2006/01/13 14:20:21 -, Michael Deckers wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL Then why can the IERS express UTC in the MJD notation? Good point. The only such usage I am aware of is in IERS Bulletin A where the MJD column is given without saying even whether it's UTC, TAI, UT1, or something else. In fact, in the situation where it's used the accuracy doesn't warrant it. Mark Calabretta ATNF
Re: The real problem with leap seconds
On Fri 2006/01/13 11:45:13 -, Ed Davies wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL If you don't count the leap seconds then the good news is that days are all 86 400 seconds long but the bad news is that the real is undefined during the leap second and there's a discontinuity (or rather, a surprising continuity in that at some point it's 23:59:59.99 and a whole second and a tiny bit later it's 00:00:00.). Agreed. I would add that two occasions when you would do this is in computing UT1 and time_t. The use of the 23:59:60 notation is described in ISO 8601. Is it also specified in TF.460? If so, how do they relate it to the notion of DTAI? In practice, refer to the example I gave on Jan/12. Mark Calabretta ATNF
Re: The real problem with leap seconds
On Fri 2006/01/13 16:45:33 -, Michael Deckers wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL Right, UTC timestamps are ambiguous (in the sense that the ... would have been ambiguous ... corresponding TAI value is not known) in the vicinity of positive leap seconds, and the notation with a second field = 60 s is one (elegant) way to disambiguate. ... had not the variable-radix notation not been introduced. Another way to disambiguate is to record the value of DTAI together with a UTC (or TAI) timestamp. Such a method is standardised in ISO 8601 for denoting offsets from UTC, but only with minute resolution. I seem to remember that Clive Feather once proposed this for an extension to the C programming language. ... where UTC here is taken to be in the usual (fixed-radix) sexagesimal format. Mark Calabretta ATNF
Re: 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.
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
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.
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: 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: The real problem with leap seconds
Yes: there is an order on the set of values of timescales - it is a basic property of spacetime models that one can distinguish past and present, at least locally. Spacetime is a differentiable 4-dimensional manifold, its coordinate functions are usually two times differentiable or more. In particular, the set of values of timescales does indeed have a topology (which is Hausdorff). Sure - this is a reasonable definition of timescale, but I don't think it is wide enough to include UTC. As I understand it, and everyone will correct me if I'm wrong, UTC is not intended to be directly related to spacetime coordinates at all. UTC is (currently) an aproximation to the direction the earth is facing and is adjusted according to how long it takes the earth to end up facing the same direction again. All of this is completely independent from the choice of a particular calendar or of the time units to be used for expressing timescale values. I'd agree with this for TAI (including that it should be the integral of a nice 1-form), but I'm not so sure for UTC. If you subtract a time from a timescale value, you get another timescale value. If you mean to say that UTC takes its values in a different space than TAI then you cannot agree with UTC = TAI - DTAI, as in the official definition of UTC. And if you say that UTC - TAI can be discontinuous (as a function of whatever) with both UTC and TAI continuous then you must have a subtraction that is not continuous. Strange indeed. Where did I misinterpret your post? Yep - you've picked up my intent correctly. I'm saying that subtraction is a stange operator taking a UTC value and a TAI value and gives you something that's a real number. The reason that I came to this conclusion is because none of the documents I've read say that UTC can be expressed as a real number - they all suggest it is expressed as labelled seconds. (For example, see the way that Rec. 460-4 gives UTC values - I've never seen an official looking document that tries to write UTC as a real.) David.
Re: The real problem with leap seconds
On 2006-01-10, Mark Calabretta wrote: I can't let this one pass - UTC is continuous and monotonic. In fact, ignoring differences in origin, UTC = TAI. Surprised? If so then you're confusing a quantity with its representation (though in good company in doing so). I do not understand. As a function of TAI, UTC is neither continuous nor monotone increasing in the mathematical sense. In the defining document, [ITU-R TF.460-6], UTC is given as UTC = TAI - DTAI where DTAI is a step function of TAI assuming as values only integral multiples of 1 s. Unless constant, such a function is not continuous on a connected domain in the mathematical sense. Hence, UTC is not a continuous function of TAI. At some instant when TAI took a value in the positive leap second between 2006-01-01 + 00 h + 00 min + 32 s and 2006-01-01 + 00 h + 00 min + 33 s (the exact instant is not clear from [ITU-R TF.460-6 2002]), DTAI jumped from 32 s to 33 s; thus, UTC is not a monotone increasing function of TAI either. Perhaps you consider UTC as a function of something other than TAI where it may well be continuous or monotone (eg, as a function of itself, UTC trivially is both continuous and monotone). Reference: [ITU-R TF.460-6] Recommendation ITU-R TF.460-6 Standard-frequency and time-signal emissions. 2002 Geneva. Michael Deckers
Re: The real problem with leap seconds
[A lot of discussion on this list seem to revolve around people understanding terms in different ways. In an impractical example of that spirit...] I do not understand. As a function of TAI, UTC is neither continuous nor monotone increasing in the mathematical sense. To say if TAI is a monotone function of UTC, you need to put an order on the set of possible TAI and UTC values. To say if UTC is a continious function of TAI, you need to put a topology on both. To me, TAI seems to be a union of copies of [0,1) labelled by YEAR-MM-DD HH:MM:SS where you glue the ends together in the obvious way and SS runs from 00-59. You then put the obvious order on it that makes it look like the real numbers. OTOH, UTC seems to be a union of copies of [0,1) labelled by YEAR-MM-DD HH:MM:SS where SS runs from 00-60. You glue both the end of second 59 and 60 to the start of the next minute, in adition to the obvious glueing. I haven't checked all the details, but seems to me that you can put a reasonable topology and order on the set of UTC values that will make UTC a continious monotone function of TAI. The topology is unlikely to be Hausdorf, but you can't have everything. DTAI jumped from 32 s to 33 s; thus, UTC is not a monotone increasing function of TAI either. Since DTAI involves subtracting quantities that aren't real numbers, you can't conclude that a discontinuity in DTAI results in a discontinuity in UTC. David.
Re: The real problem with leap seconds
On 11 Jan 2006 at 0:08, Tim Shepard wrote: If humans spread out to other places besides the earth, an earth-centric time scale might begin to seem somewhat quaint. Distributing leap second information to a Mars colony seems kind of silly. As I recall, the NASA Mars missions are using Mars-centric time scales, which include a Martian second that has a different length from the SI second in order for the different-length Martian day (called a Sol) to be subdivided into a familiar 24 hours composed of 60 minutes each with 60 seconds. If, however, this Martian second is actually defined as a particular multiple of the SI second, then the use of leap seconds on Mars would ultimately be necessary to account for any future changes in the length of the Martian day. -- == Dan == Dan's Mail Format Site: http://mailformat.dan.info/ Dan's Web Tips: http://webtips.dan.info/ Dan's Domain Site: http://domains.dan.info/
Re: The real problem with leap seconds
On Wed 2006-01-11T09:01:07 -0500, Daniel R. Tobias hath writ: If, however, this Martian second is actually defined as a particular multiple of the SI second, then the use of leap seconds on Mars would ultimately be necessary to account for any future changes in the length of the Martian day. The martian second in their case is defined purely for the sake of the local solar time of the solar powered rovers which are effectively stationary on the planet. Something akin to the long-used Newcomb expression for mean solar time is more than sufficient. In that respect the rovers are sundials. The mission clock on the lander has a more uniform time scale used for the sake of such things as the cool photos of the martian moons transiting the sun. Leap seconds for Mars seem irrelevant until there are VLBI antennae on Mars performing routine observations. The atomic clocks used by such VLBI antennae will not, however, keep synchronized with earth using anything less than a fully general relativistic expression for the intercomparisons. -- Steve Allen [EMAIL PROTECTED]WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
Re: The real problem with leap seconds
On 2006-01-11, David Malone wrote: [A lot of discussion on this list seem to revolve around people understanding terms in different ways. In an impractical example of that spirit...] Anyway: excuse me for repeating some basics of classical mechanics; but I believe it to be necessary. To say if TAI is a monotone function of UTC, you need to put an order on the set of possible TAI and UTC values. To say if UTC is a continuous function of TAI, you need to put a topology on both. Yes: there is an order on the set of values of timescales - it is a basic property of spacetime models that one can distinguish past and present, at least locally. Spacetime is a differentiable 4-dimensional manifold, its coordinate functions are usually two times differentiable or more. In particular, the set of values of timescales does indeed have a topology (which is Hausdorff). To me, TAI seems to be a union of copies of [0,1) labelled by YEAR-MM-DD HH:MM:SS where you glue the ends together in the obvious way and SS runs from 00-59. You then put the obvious order on it that makes it look like the real numbers. TAI is determined as a weighted mean of the (scaled) proper times measured by an ensemble of clocks close to the geoid - so the values of TAI must belong to the same space as these proper times, which (being line integrals of a 1-form) take their values in the same space as the time coordinates of spacetime (such as TCB and TCG). No gluing is needed. And yes: this space is diffeomorphic to the real line. All of this is completely independent from the choice of a particular calendar or of the time units to be used for expressing timescale values. OTOH, UTC seems to be a union of copies of [0,1) labelled by YEAR-MM-DD HH:MM:SS where SS runs from 00-60. You glue both the end of second 59 and 60 to the start of the next minute, in adition to the obvious glueing. I haven't checked all the details, but seems to me that you can put a reasonable topology and order on the set of UTC values that will make UTC a continious monotone function of TAI. The topology is unlikely to be Hausdorf, but you can't have everything. If you subtract a time from a timescale value, you get another timescale value. If you mean to say that UTC takes its values in a different space than TAI then you cannot agree with UTC = TAI - DTAI, as in the official definition of UTC. And if you say that UTC - TAI can be discontinuous (as a function of whatever) with both UTC and TAI continuous then you must have a subtraction that is not continuous. Strange indeed. Where did I misinterpret your post? And can you give some reference for your assertions? Michael
Re: The real problem with leap seconds
On Wed 2006/01/11 10:47:25 -, Michael Deckers wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL At some instant when TAI took a value in the positive leap second between 2006-01-01 + 00 h + 00 min + 32 s and 2006-01-01 + 00 h + 00 min + 33 s (the exact instant is not clear from [ITU-R TF.460-6 2002]), DTAI jumped from 32 s to 33 s; thus, UTC is not a monotone increasing function of TAI either. Here in a topology-free way is what the axis labels of my graph look like during the said leap second insertion: UTC axisTAI axis DTAI 2005/12/31 23:59:58 2006/01/01 00:00:3032 2005/12/31 23:59:59 2006/01/01 00:00:3132 2005/12/31 23:59:60 2006/01/01 00:00:3232 60.932.9 32 60.99 32.99 32 60.999... 32.999... 32 2006/01/01 00:00:00 2006/01/01 00:00:3333 2006/01/01 00:00:01 2006/01/01 00:00:3433 The seconds keep step and the graph has no gaps, jumps or kinks. The only difference between UTC and TAI is one of representation, like the current year which may be represented as 2006 or MMVI but it's still the same year. Mark Calabretta ATNF
Re: The real problem with leap seconds
In message: [EMAIL PROTECTED] Mark Calabretta [EMAIL PROTECTED] writes: : On Wed 2006/01/11 10:47:25 -, Michael Deckers wrote : in a message to: LEAPSECS@ROM.USNO.NAVY.MIL : :At some instant when TAI took a value in the positive leap second between :2006-01-01 + 00 h + 00 min + 32 s and 2006-01-01 + 00 h + 00 min + 33 s :(the exact instant is not clear from [ITU-R TF.460-6 2002]), DTAI jumped :from 32 s to 33 s; thus, UTC is not a monotone increasing function of :TAI either. : : Here in a topology-free way is what the axis labels of my graph look : like during the said leap second insertion: : : UTC axisTAI axis DTAI :2005/12/31 23:59:58 2006/01/01 00:00:3032 :2005/12/31 23:59:59 2006/01/01 00:00:3132 :2005/12/31 23:59:60 2006/01/01 00:00:3232 : 60.932.9 32 : 60.99 32.99 32 : 60.999... 32.999... 32 :2006/01/01 00:00:00 2006/01/01 00:00:3333 :2006/01/01 00:00:01 2006/01/01 00:00:3433 : : The seconds keep step and the graph has no gaps, jumps or kinks. Shouldn't the DTAI increment for the leap second? That's the point of the leap second... Or is that only needed when you do the POSIX time_t thing of repeating 59? In computer science, regular things are easy. Irregular ones are hard and prone to errors. The :60 kludge makes a regular 1-1 mapping function for time into a table driven nightmare :-(. : The only difference between UTC and TAI is one of representation, like : the current year which may be represented as 2006 or MMVI but it's still : the same year. The point isn't that one can construct a 'second labelling' that is unambiguous, monotonic and increasing, but rather that when one distills the UTC time down to a single number, you necessarily have ambiguities and discontinuties in that function. Of course there's an implicit assumption that the conversion function is the same as POSIX's time_t, otherwise you would be using TAI or a count of actual seconds. We call it PPSes or pulses at work to distinguish it. We label UTC time as having leap seconds swizzled in, and TAI time as unswizzled. Warner
Re: The real problem with leap seconds
On Wed 2006/01/11 20:58:25 PDT, M. Warner Losh wrote in a message to: [EMAIL PROTECTED] and copied to: LEAPSECS@ROM.USNO.NAVY.MIL : 60.999... 32.999... 32 :2006/01/01 00:00:00 2006/01/01 00:00:3333 :2006/01/01 00:00:01 2006/01/01 00:00:3433 : : The seconds keep step and the graph has no gaps, jumps or kinks. Shouldn't the DTAI increment for the leap second? It goes from 32 to 33 at precisely 2006/01/01 00:00:00 (UTC) (or at precisely 2006/01/01 00:00:33 (TAI) if you prefer), as shown in the above table. Refer to the last page of the current IERS Bulletin A, Vol. XIX No. 1, ftp://maia.usno.navy.mil/ser7/ser7.dat, which says the same as above though in a little less detail. That's the point of the leap second... Or is that only needed when you do the POSIX time_t thing of repeating 59? My comments on discontinuity etc. do not apply to time_t which is not the same thing as UTC. In computer science, regular things are easy. Irregular ones are hard and prone to errors. The :60 kludge makes a regular 1-1 mapping function for time into a table driven nightmare :-(. It sure does. The point isn't that one can construct a 'second labelling' that is unambiguous, monotonic and increasing, but rather that when one distills the UTC time down to a single number, you necessarily have ambiguities and discontinuties in that function. time_t has ambiguities and discontinuties, but that is not a necessary consequence of leap seconds. To their credit the CCIR did not stuff up in specifying the clock notation to be used for UTC. Mark Calabretta ATNF
Re: The real problem with leap seconds
On Mon, 9 Jan 2006, Tim Shepard wrote: wot, no attribution of quotes? and you still cannot even get it [TAI] reliably from your I still think NTP should have distribute TAI, but I understand using Was your failure to form a past-participle a Freudian slip? I'm with you if you really mean NTP should distribute TAI!!! Pete.
Re: The real problem with leap seconds
I still think NTP should have distribute TAI, but I understand using Was your failure to form a past-participle a Freudian slip? I'm with you if you really mean NTP should distribute TAI!!! Uh, probably yes. I didn't even see the grammer error when I re-read it the first time just now. About 15 years ago I came to believe that it would have been better if NTP distributed TAI instead of (or perhaps alongside) UTC. And yes, I still believe that. Now I think it would be best if TAI and UTC were both distributed by time signals (and NTP, etc), with equal emphasis to make it clear to all users that they have a choice to make. Atomic time based on the SI second (TAI) and traditional time based on earth orientation (UT) are both needed in the modern world. Both should be distributed. People who have some need to synchronize clocks should be forced to decide which kind of time would be best for them. (Or perhaps in some cases it would be best for them to implement both side-by-side in their system.) A system which distributes TAI (which never has leap seconds) and also distributes the current number of seconds of offset for UTC, as well as leap warnings (or continuously broadcasts the table of all known (past and scheduled) leap seconds), would seem to be reasonable. This would allow the decisions about what would be the best time scale to use to be made downstream. Build good mechanisms that allow a variety of policies, and leave policies to those downstream of you. My preference would be for civil time keeping to continue to be tied to earth orientation, as it was when GMT was the standard. So UT1 or UTC would continue to be normal time, and TAI (or something like it) would be the weird time that certain geeks care about. The other alternative would be for civil timekeeping to be based on TAI (something which never has leap seconds), with UTC (or something like it) to be the weird time that certain geeks care about. This is the radical proposal, but I can understand that some would want to do this. If humans spread out to other places besides the earth, an earth-centric time scale might begin to seem somewhat quaint. Distributing leap second information to a Mars colony seems kind of silly. (Though I guess that those on a Mars colony would in fact care about earth orientation, e.g. if they wished to communicate with friends back on Earth using their amateur laser-communication gear in their backyards.) I very much dislike the proposal to *redefine* UTC to abolish leap seconds. I dislike very much trying to understand code that was written with descriptive names (for variables, functions, constants, etc) but which has evolved such that what the names apparently mean and what they really mean are very different. UTC is a type of UT time. If you stop putting leap seconds in UTC to keep it close to all the other UT time scales, then it no longer deserves to have a name that starts with UT. So fine, if we must stop maintaining UTC with leap seconds and move civil time keeping users to some sort of new standard, please do *not* call it UTC after the change. The hack of having UTC ticks align with TAI ticks and adjusting UTC with leap seconds was perhaps not the best idea. But it was done, and has been in place for more than 30 years, and is now a widely implemented and understood standard. If this hack should be replaced with something better (and perhaps it should be), I'd want 20 years advance notice that a change is coming, and 15 years advance notice as to what exactly the change will be. (I suspect though I won't get that much notice.) leap hours are a horrible idea, whether they be leap hours inserted in to some UTC-like global standard, or by local jurisdictions. Well, those are my opinions. Thanks for listening. -Tim Shepard [EMAIL PROTECTED]
Re: The real problem with leap seconds
Tim Shepard scripsit: [many sensible opinions snipped] leap hours are a horrible idea, whether they be leap hours inserted in to some UTC-like global standard, or by local jurisdictions. I understand what's wrong with the former kind, but what's wrong with the latter? Why do you think they are more of a problem than DST shifts? -- Andrew Watt on Microsoft: John Cowan Never in the field of human computing [EMAIL PROTECTED] has so much been paid by so manyhttp://www.ccil.org/~cowan to so few! (pace Winston Churchill) http://www.reutershealth.com
Re: The real problem with leap seconds
In message [EMAIL PROTECTED], Clive D.W. Feather writes: The real problem is not the 23:59:60, it's *predicting* when they happen. I agree, the short prediction horizon is the major problem. But 23:59:60 _is_ a problem too. I don't think anybody dare even think about redefining POSIX time_t and even if they did redefine it to contain leap-seconds, many tons of software wouldn't be updated/recompiled to take advantage of it. So the standards crew, POSIX, LSB or whoever would have to come up with a new data type for holding timestamps, and while a number of proposals have been floated over the years, none of them seem to contain any real clue, so I don't think this is likely to happen. But pressume for a moment that they did come up with a new standard, the many tons of software would still not be rewritten to take advantage of it, so we'd still be stuck with time_t's ostrich behaviour for the forseeable future. Unlikely as it is, it would allow people like Warner and me to write software that Do The Right Thing. A far more sensible idea is to just forget about leap-seconds from now on, leave DUT1 to wander, tell BIPM/IERS to provide a contemporary kind of service (internet services instead of handwritten letters), the astronomers to shut upcope and leaving the issue of the length of day in 500 years to the people who live 500 years from now on. It's the comparison between educating all programmers in the world vs having the astronomers use a DUT which is larger than 1 second. There is no doubt that from a humanistic point of view it would be better to educate all the programmers, but considering that I still suffer from web-forms that insist I enter a USA style phone number when I have entered Denmark as country, this is a far moure daunting task than it might appear. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
I wrote: Right now, the DTAI(TAI) function is the sum of a set of Kroneker delta functions. Thanks to David for quietly pointing out that I meant Heaviside step functions, not Kroneker delta functions. -- Clive D.W. Feather | Work: [EMAIL PROTECTED] | Tel:+44 20 8495 6138 Internet Expert | Home: [EMAIL PROTECTED] | Fax:+44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc||
Re: The real problem with leap seconds
In message [EMAIL PROTECTED], Peter Bunclark writes: On Mon, 9 Jan 2006, Poul-Henning Kamp wrote: I don't think anybody dare even think about redefining POSIX time_t I wish people would stop making positive assertions about what other people are bound to think. What you mean in is, YOU are against suggesting changing (or augmenting) POSIX time. No, I mean exactly what I wrote: I don't think anybody dare even think about redefining POSIX time_t The reason I mean that is that I've talked to a lot of the relevant people and they're all totally morified about the consequences of (time_t % 86400) not giving you the time of day. Remember, most of these people are even afraid to extend time_t to 64 bits because of the possible fall-out :-( -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
Poul-Henning Kamp said: So the standards crew, POSIX, LSB or whoever would have to come up with a new data type for holding timestamps, We already have one: struct tm. There is no doubt that from a humanistic point of view it would be better to educate all the programmers, but considering that I still suffer from web-forms that insist I enter a USA style phone number when I have entered Denmark as country, this is a far moure daunting task than it might appear. Amen. [I happen to have a US Social Security number, which allows me to confuse some web pages back.] -- Clive D.W. Feather | Work: [EMAIL PROTECTED] | Tel:+44 20 8495 6138 Internet Expert | Home: [EMAIL PROTECTED] | Fax:+44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc||
Re: The real problem with leap seconds
M. Warner Losh wrote on 2006-01-09 16:57 UTC: There's been many many many people that have tried to fix POSIX time_t. One person's fix is another person's recipe for disaster ... The POSIX definition of time_t is not quite as broken as some individuals would like you to believe. It actually does its job very well, especially out there in the real world, where UTC is easily and reliably available from many, many, independent channels. The same surely could not (and probably still cannot) be said for TAI and for automatic leap-second table updates. You cannot get TAI from the BBC evening news, and you still cannot even get it reliably from your average local NTP server. (I know, we've already discussed this here, on [EMAIL PROTECTED], on pasc-time-study, and on austin-group-l in *very* great detail, many, many, many times, so I'll stop.) Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Re: The real problem with leap seconds
From: Markus Kuhn [EMAIL PROTECTED] Subject: Re: [LEAPSECS] The real problem with leap seconds Date: Mon, 09 Jan 2006 19:12:05 + M. Warner Losh wrote on 2006-01-09 16:57 UTC: There's been many many many people that have tried to fix POSIX time_t. One person's fix is another person's recipe for disaster ... True. All the fixes are worse than the disease. However, let us not forget that the disease is still bad. The POSIX definition of time_t is not quite as broken as some individuals would like you to believe. It actually does its job very well, especially out there in the real world, where UTC is easily and reliably available from many, many, independent channels. True. The same surely could not (and probably still cannot) be said for TAI and for automatic leap-second table updates. You cannot get TAI from the BBC evening news, and you still cannot even get it reliably from your average local NTP server. False. Leap second tables are readily available. Current offset between UTC and TAI is generally available (or computable) from many time broadcasts (although not all). (I know, we've already discussed this here, on [EMAIL PROTECTED], on pasc-time-study, and on austin-group-l in *very* great detail, many, many, many times, so I'll stop.) POSIX's time_t is broken. Very broken. It is broken accross leap seconds, and other times. It is convenient because one can get a decent notion of UTC from many places. However, it is equally easy to get a notion of TAI time as well, with very minimal effort. One can easily look on IERS' web page, or download the current leap second table from ftp://time.nist.gov/pub/leap-seconds.list with very minmal effort. When you have a leap second table, you can run in TAI and compute intervals correctly. When you don't have a leap second table, you can run in UTC, but cannot compute intervals correctly (accross leap seconds). Which set of problem do you want to have? The answer will very much depend on how connected you are and what the negative consequences are of computing time intervals wrong are. My applications tend to be unconnected with big consequences if intervals are computed wrong, which is the worst of both worlds. Anyway, time_t is like goto. Sure, you can use it. Sure it usually won't get you into trouble, but it is being badly abused and that abuse causes real problems for people that care about accuracy. Warner
Re: The real problem with leap seconds
In message [EMAIL PROTECTED], Markus Kuhn writes: and you still cannot even get it reliably from your average local NTP server. This is a circular argument: The reason NTP doesn't provide it is that time_t needs UTC. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
and you still cannot even get it [TAI] reliably from your average local NTP server. This is a circular argument: The reason NTP doesn't provide it is that time_t needs UTC. No, I asked David Mills about 15 or so years ago why NTP distributes UTC and not TAI (me thinking and suggesting that it would have been so much better if NTP distributed TAI) and the reason was quite simple: There was no convenient way to get TAI. The time signals broadcast by WWV and WWVB in the US distributed UTC and leap warning bits, but did not distribute (and still do not AFAIK) what the TAI offset is. GPS receivers were (very) rare back then, so getting GPS time and subtracting out the constant offset to get back to TAI was not a viable option either (though perhaps it would be today, as long as the GPS system keeps running). I still think NTP should have distribute TAI, but I understand using TAI was not practicable option when NTP was designed. BTW, I don't know if the Fuzzball OS had any Posix time_t's in it, or anything resembling them, but I suspect not. I vaguely recall hearing that it had some other way of keeping the time in a collection of 16-bit registers (PDP-11s, don't you know). -Tim Shepard [EMAIL PROTECTED]
Re: The real problem with leap seconds
On Mon 2006/01/09 10:01:27 -, Clive D.W. Feather wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL I've just read through the email that has accumulated on this list since before xmas - impressive volume! Why not devote a fraction of that time and energy to producing a formal position paper. You've expressed it very badly in the article. ...and you've expressed this rather tactlessly! The problem is not that UTC can't be expressed as a real number. Rather (and you do sort of say this, just not very well), the function UTC(TAI) is not continuous and monotonic. I can't let this one pass - UTC is continuous and monotonic. In fact, ignoring differences in origin, UTC = TAI. Surprised? If so then you're confusing a quantity with its representation (though in good company in doing so). First consider a graph of a person's age versus calendar date with a precision of 1 day. The fields in calendar dates are mixed-radix, the day field is also variable-radix depending on the month, and for February the year, so how should we plot the calendar axis? Simple, do it as a count of days and then label it with year, month and day-of- month; Feb/29 in leap years comes out in the wash. As expected, the graph is a continuous straight line of slope 1 - no breaks, no kinks - the person doesn't age in fits and starts! Now consider extending this graph to sub-second precision, accounting for leap seconds, with age to be measured in TAI and calendar date in UTC. Now the date axis must be constructed as a count of seconds of UTC (SI seconds, same as TAI) measured from birth. As before label the date axis using conventional calendar/clock notation. The graph is still a continuous straight line of slope 1 (no breaks, no kinks). Leap seconds are labelled as 23:59:60 - that is the formal representation, each second of UTC has a unique label as required for mathematical validity. (Note that it is incorrect to repeat the seconds count at 59, 00, 01 or anywhere else, even though that may be required on clock displays for practical reasons.) Doing arithmetic on UTC using clock notation is like doing arithemetic on calendar dates or with numbers using Roman numerals. The principle difference is that leap days follow a set rule and computations involving future times can be performed, whereas leap seconds do not follow a set rule and computations cannot be performed into the future. I am reminded of a discussion concerning the curious repetition of 1828 in e = 2.718281828... Simply reexpress the number in base 2, base e, or something else; the pattern disappears. Mark Calabretta ATNF
Re: The real problem with leap seconds
On Mon 2006/01/09 10:38:54 -, Peter Bunclark wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL I't be interesting to do an FFT on this list, and see if some of the contributers actually ever sleep, or do any other work... I had the same thought - the moreso when I reflect on the nil response to my request for a counter-presentation at ADASS. (What sort of FFT did you have in mind?) Cheers, Mark
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
In message [EMAIL PROTECTED], Ed Davies writes: 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? As I understood it, it was mainly that TAI is a post-factum postal timescale. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
On Jan 8, 2006, at 5:38 AM, Poul-Henning Kamp wrote: As I understood it, it was mainly that TAI is a post-factum postal timescale. One is left pondering the fact that UTC is now (and would remain under any changes I've heard suggested) a time scale based on TAI. What magic makes one acceptable and the other not?
Re: The real problem with leap seconds
In message [EMAIL PROTECTED], Steve Allen writes: On Sat 2006-01-07T21:20:33 +0100, Poul-Henning Kamp hath writ: Well, the BIPM doesn't really want anybody to use TAI, their director said as much last year The Italian contribution to the November 2005 WP7A meeting could be interpreted a suggestion that the international agencies in charge of time scales need to get their heads together, pick one time scale with no discontinuities, and abolish all others. That sounds like the sensible partys platform to me. Doing so would once and for all have to divorce earth orientation from that unified time scale, leaving it to governments to align civil time with daylight as they see fit (just like today). Klepczynski had implied that more clearly on pages 322 and 323 of http://tycho.usno.navy.mil/ptti/ptti2004/panel.pdf where he discusses getting all the satellite navigation systems to use a single time scale. It is the time scale that is the issue, it's the clock offset between the systems. If you have 2 GPS sats, one GLONASS and one GALILEO, you also need to know the clock offsets between the three systems before you can calculate a position. If everybody gets their act together and hold the clock offsets small, then it would be a wonderful world indeed, but I think the practical, organizational and political problems will prevent that. The other option is for the systems to broadcast their clock offsets relative to the other systems. For that to help rapid first fix it must be a frequent broadcast (ie: non-almanac) otherwise you might as well just wait until you get four birds in one system. (And to see that psychology is not just relevant to astronomers, read Matsakis on page 336.) Yes, astronomers have psychology too, but the comments on that page has nothing to do with leap seconds at all. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
In message [EMAIL PROTECTED], Rob Seaman writes: On Jan 8, 2006, at 5:38 AM, Poul-Henning Kamp wrote: As I understood it, it was mainly that TAI is a post-factum postal timescale. One is left pondering the fact that UTC is now (and would remain under any changes I've heard suggested) a time scale based on TAI. What magic makes one acceptable and the other not? I didn't say I thought the protest against more widespread use made sense, I merely tried to relay it faithfully. I does sound consistent with previously mentioned old fashionedness. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
In message: [EMAIL PROTECTED] Poul-Henning Kamp [EMAIL PROTECTED] writes: : In message [EMAIL PROTECTED], Ed Davies writes: : 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? : : As I understood it, it was mainly that TAI is a post-factum postal : timescale. How is it that UTC can be realized in realtime, but TAI isn't. I thought the difference between the two was an integral number of seconds, by definition. Is that understanding flawed? Wanrer
Re: The real problem with leap seconds
On Sun 2006-01-08T11:44:04 -0700, M. Warner Losh hath writ: How is it that UTC can be realized in realtime, but TAI isn't. I thought the difference between the two was an integral number of seconds, by definition. Is that understanding flawed? I believe the claim would be that UTC(insert your national time service here) is realized in real time. UTC(USNO) is the official time of the US, and I suspect that there would be loss of face if any agency charged with keeping a national time did not, in some sense, proclaim autonomy. UTC(pick one) is, of course, directly related to TAI(pick one). TAI(anywhere) has no official status anywhere, except in the ex post facto statistical sense that it contributes to TAI (unmodified, the real thing from the BIPM). In an official sense of operational time scales, it is not clear that there really is anything such as UTC (plain old, unmodified) which differs from TAI by an integral number of seconds. As an identifiable entity, UTC (unmodified) may only exist within the text of ITU-R TF.460 -- Steve Allen [EMAIL PROTECTED]WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
Re: The real problem with leap seconds
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 -- Steve Allen [EMAIL PROTECTED]WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
Re: The real problem with leap seconds
In message [EMAIL PROTECTED], Michael Sokolov writes: http://ivan.Harhan.ORG/~msokolov/articles/leapsecs.txt In this rather humorous document you have managed to say that POSIX screwed up badly. We already knew that :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
In message [EMAIL PROTECTED], Ed Davies writes: Also, Markus wasn't proposing UTS as a civil timescale but just for use within computer systems, etc. What a weird concept... Why not go the full distance and define a timescale for each particular kind of time-piece: Wrist Watch time Wall clock time Grandfather clock time Tower clock time Television time Embedded system time Appliance time Router time PC time Windows server time Commercial UNIX time Free UNIX time Main-frame time and give each of them their own unique way of coping with leapseconds ? Ohh wait... That's what it looks like today already isn't it ? :-( -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
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
In message [EMAIL PROTECTED], Ed Davies writes: Ignoring the ridiculous parody - no, it's not a weird concept. Different timescales are useful for different purposes. Get used to it. I have no problems with different timescales for different purposes. For instance I very much wish the Astronomers would start to use UT1, which is very much their timescale, and stop abusing UTC, which isn't, as a convenient approximation. But I have big problems with people who want to introduce more timescales without thinking through the legal and technical complications. The question is, where in the range of possible timescales is it most useful to put civil time. Civil time is in the hands of individual governments, and they tend to expect their computers to use the same time as the rest of their country. Nobody here is in any position to do anything about civil time or legal time, neither are we in a position to introduce a computer time scale in a pathetic attempt to paste over leap seconds. We can talk about _representation_ of a given timescale in computers, but there are far too many laws to rewrite if we want to dictate which timescale they should use. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
Hi Ed, 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. I was contemplating an answer along the same lines. Yours is much superior. Rob
Re: The real problem with leap seconds
Ed Davies scripsit: (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.) Well, yes. But that's a matter of verbal labels. The Gregorian calendar extends to all future time: what is not known is the date on which it will be replaced in civil use by a further refinement. We know we will need one eventually, both because of the current annual discrepancy of about 27 seconds between the Gregorian and tropical years, and because of future changes in the length of the tropical year. -- John Cowan [EMAIL PROTECTED] www.reutershealth.com www.ccil.org/~cowan If a traveler were informed that such a man [as Lord John Russell] was leader of the House of Commons, he may well begin to comprehend how the Egyptians worshiped an insect. --Benjamin Disraeli
Re: The real problem with leap seconds
Steve Allen scripsit: The changes in the length of any kind of year are slight by comparison to the changes in length of day. Neglecting short period variations the length of the sidereal year has not changed much in a billion years. That is to say, the current best approximation to the n-body problem of the Solar System says that it hasn't. Fair enough. I merely threw that in in case it was an issue. The Gregorian calendar was designed to match the vernal equinox year. Thanks for the correction. The new fields being added to GPS signals make them able to count leap seconds for 3 years. That's quite an example of engineering margin. Indeed. But then so is IPv6 (if we ever get it adopted widely). -- John Cowan [EMAIL PROTECTED] www.ccil.org/~cowan www.reutershealth.com In the sciences, we are now uniquely privileged to sit side by side with the giants on whose shoulders we stand. --Gerald Holton
Re: The real problem with leap seconds
On Sat, Jan 07, 2006 at 04:02:04PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Ed Davies writes: Ignoring the ridiculous parody - no, it's not a weird concept. Different timescales are useful for different purposes. Get used to it. I have no problems with different timescales for different purposes. For instance I very much wish the Astronomers would start to use UT1, which is very much their timescale, and stop abusing UTC, which isn't, as a convenient approximation. But I have big problems with people who want to introduce more timescales without thinking through the legal and technical complications. Yes And with people that want to redefine existing time scales so they mean one thing in one era, and another thing in a different era. As happened with GMT, or the proposed changes to UTC. The question is, where in the range of possible timescales is it most useful to put civil time. Civil time is in the hands of individual governments, and they tend to expect their computers to use the same time as the rest of their country. Yes again. And they are free to choose TAI if they want a uniform time scale. But why take the choice of a UTC that remains within 0.9s of the earth's average rotation rate? Nobody here is in any position to do anything about civil time or legal time, neither are we in a position to introduce a computer time scale in a pathetic attempt to paste over leap seconds. Here we disagree. I guess you're confirming what is in fact the current problem as I see it. We're here because an ITU committee, shrouded in secrecy, is trying to redefine UTC and the international distribution of time signals, which most jurisdictions rely on one way or another as civil time. But the way the ITU works undermines the sort of open and informed discussion that is necessary for an issue so sweeping in its legal, practical and philosophical implications. The thing that is most flawed here is the process. We can talk about _representation_ of a given timescale in computers, but there are far too many laws to rewrite if we want to dictate which timescale they should use. But it is inappropriate for ITU to do an end-run around the laws, and redefine the timescale so that it swings an extra hour back and forth. Some folks here suggest that legislatures just change their timezones periodically, forced by the actions of the ITU. But data was presented in Torino suggesting a cost to NASA and US DoD of a half a billion dollars to study, re-engineer and test their systems if UTC diverges markedly from UT1. Not an easy thing for a legislature to deal with. Again - it's a process problem The only time there has been an inclulsive international meeting devoted to the issue, at the colloquium in Torino, There was no overwhelming consensus on whether the status quo should be maintained or an alternative should be pursued. But If a change were to be made one alternative appeared to be preferred. The essence of this alternative was as follows: 1. Any change should slowly evolve from the current UTC Standard in transitioning to a uniform timescale, perhaps to be called Temps International (TI). 2. A suggested date for inaugurating any change would be 2022, the 50 TH anniversary of the UTC timescale. The date suggested is influenced by the lifetimes of existing systems that would be expensive to change. [http://www.ien.it/luc/cesio/itu/annex_a.pdf] So it is distressing to see committee members of the ITU headed in a different direction. Neal McBurnett http://bcn.boulder.co.us/~neal/ Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60 Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
In message [EMAIL PROTECTED], Neal McBurnett writes: Civil time is in the hands of individual governments, and they tend to expect their computers to use the same time as the rest of their country. Yes again. And they are free to choose TAI if they want a uniform time scale. But why take the choice of a UTC that remains within 0.9s of the earth's average rotation rate? 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. The snippy answer to why UTC was adopted for civil timekeeping would be Because they got bad advice, but that would be grossly unfair since nobody (but possibly Dave Mills) at that time could be expected to foresee what computer networks would result in and how that would affect the needs for timekeeping. Just like the variable rate atoms of the sixties where a bad idea we now know that the variable length days that replaced them are bad. I'm not old enough to have any axe to grind about the last couple of redefinitions of time, but I can see where they both went wrong (insisting on using the unprecise and unstable clock to discipline the stable and precise clock) and I want us to stop that mistake. Here we disagree. I guess you're confirming what is in fact the current problem as I see it. We're here because an ITU committee, shrouded in secrecy, is trying to redefine UTC and the international distribution of time signals, which most jurisdictions rely on one way or another as civil time. But you overlook that ITU is an international organization under the UN aegis. If ITU in their plenary assembly decides to do something, no matter how stupid, (X.400 for example), that is nontheless the will of the governments of the world. You can find locate your countrys ITU-R representative and contact them with your input, just as well as I can for mine. There is nothing hidden, undemocratic or revolutionary about it. The ITU _process_ does actually work. I will agree that a lot of what ITU churns out, UTC with leapseconds and X.400 being my best examples, are rubbish. Some folks here suggest that legislatures just change their timezones periodically, forced by the actions of the ITU. But data was presented in Torino suggesting a cost to NASA and US DoD of a half a billion dollars to study, re-engineer and test their systems if UTC diverges markedly from UT1. Not an easy thing for a legislature to deal with. Again - it's a process problem Let me channel something that gets said a lot here: They should have used the right timescale from the beginning. It sounds like they should have used UT1, doesn't it ? And why is it that IT related costs matter so much if they come from people worried about the effect of lack of leapseconds, while at the same time, they don't matter at all if they come from people worried about the effect of leapseconds ? Clearly what's good for the goose is good for the gander, right ? The only time there has been an inclulsive international meeting devoted to the issue, at the colloquium in Torino, There was no overwhelming consensus on whether the status quo should be maintained or an alternative should be pursued. ... at that meeting. The only consensus that matters is the ITU-R SG7A, which coincidentally didn't reach one either. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
In message: [EMAIL PROTECTED] Daniel R. Tobias [EMAIL PROTECTED] writes: : On 7 Jan 2006 at 16:02, Poul-Henning Kamp wrote: : : Civil time is in the hands of individual governments, and they : tend to expect their computers to use the same time as the : rest of their country. : : And, in many countries (including the United States), the legally- : defined civil time is the mean solar time at some particular spot, or : a fixed or seasonally-variable offset from it. Any use of UTC-based : time scales for determining civil time in such places is merely an : approximation, currently to within a second, but perhaps varying by : greater amounts if some new timekeeping plan is adopted. Once UTC : stopped being a sufficiently-close approximation to the solar mean : time at the Prime Meridian (with sufficiently close possibly being : of differing values depending on the particular purpose), it would be : necessary to either stop using UTC for determining civil time in such : countries, or to change the law to base the civil time on UTC instead : of a solar standard. The US's legislation leaves it to the commerce department to define what the mean solar time is (or rather states that it is the mean solar time, as determined by the secretary of commerce). This is what presumably gives us leap seconds and the like in our civil time and when we insert them. This is a political function: Up to a second of tolerance is allowed and leap seconds are inserted whenever everybody else does. The same political decision could be made to say something else, since it is the folks in DC could say that a minute is close enough to solar mean and that's what we're going to do. Warner
Re: The real problem with leap seconds
On Sat 2006-01-07T21:20:33 +0100, Poul-Henning Kamp hath writ: You can find locate your countrys ITU-R representative and contact them with your input, just as well as I can for mine. You can try that, and you may succeed, but it is deceptive to assert that is easy to do. In the US the process is Byzantine. Whereas it is apparently required that draft contributions to the ITU be publicly available, it is apparently not required that their availability be published outside of predefined special interest groups. I would describe more of what I know, but given that my knowledge is assembled from little bits gleaned from unrelated documents I'm not convinced I am right. If anyone else cared to challenge me to post the rules of some other nation I'll gladly rise to the challenge and post the US rules. There is nothing hidden, undemocratic or revolutionary about it. The ITU _process_ does actually work. Agreed, you just have to be prepared to play the Byzantine games. -- Steve Allen [EMAIL PROTECTED]WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
Re: The real problem with leap seconds
In message [EMAIL PROTECTED], Steve Allen writes: On Sat 2006-01-07T21:20:33 +0100, Poul-Henning Kamp hath writ: You can find locate your countrys ITU-R representative and contact them with your input, just as well as I can for mine. You can try that, and you may succeed, but it is deceptive to assert that is easy to do. As far as I know, pretty much anybody can get observer status in the working group for a modest/outrageous (take your pick) amount of money. There is nothing hidden, undemocratic or revolutionary about it. The ITU _process_ does actually work. Agreed, you just have to be prepared to play the Byzantine games. Well, that's politics for you. Just because one doesn't like the rules doesn't mean that they're not fair. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
From [EMAIL PROTECTED] Sat Jan 7 08:03:04 2006 Received: from juno.usno.navy.mil (HELO [198.116.61.253]) ([198.116.61.253]) by ivan.Harhan.ORG (5.61.1.3/1.36) id AA14507; Sat, 7 Jan 06 08:03:03 GMT Received: from rom.usno.navy.mil by [198.116.61.253] via smtpd (for ivan.Harhan.ORG [208.221.139.1]) with SMTP; 7 Jan 2006 08:10:46 UT Received: from ROM (rom.usno.navy.mil [10.1.4.27]) by rom.usno.navy.mil (8.12.8/8.12.8) with ESMTP id k077o0kU019926; Sat, 7 Jan 2006 08:02:52 GMT Received: from ROM.USNO.NAVY.MIL by ROM.USNO.NAVY.MIL (LISTSERV-TCP/IP release 1.8e) with spool id 0549 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 08:02:52 + Received: from TS-FW.usno.navy.mil (TS-FW.usno.navy.mil [10.1.1.3]) by rom.usno.navy.mil (8.12.8/8.12.8) with SMTP id k0782pkM019980 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 08:02:52 GMT Received: from santo.ucolick.org ([128.114.23.204]) by TS-FW.usno.navy.mil via smtpd (for rom.usno.navy.mil [10.1.4.27]) with SMTP; 7 Jan 2006 08:10:36 UT Received: from localhost (localhost [127.0.0.1]) by smtp.ucolick.org (Postfix) with ESMTP id 475575D715 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 00:02:51 -0800 (PST) Received: from geneva.ucolick.org (geneva.ucolick.org [128.114.23.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.ucolick.org (Postfix) with ESMTP id D9F7C11419 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 00:02:50 -0800 (PST) Received: from geneva.ucolick.org (localhost [127.0.0.1]) by geneva.ucolick.org (8.13.1/8.12.10) with ESMTP id k0782ofC025400 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 00:02:50 -0800 Received: (from [EMAIL PROTECTED]) by geneva.ucolick.org (8.13.1/8.13.1/Submit) id k0782oFP025399 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 00:02:50 -0800 Date: Sat, 7 Jan 2006 00:02:50 -0800 From: Steve Allen [EMAIL PROTECTED] To: Leap Second Discussion List LEAPSECS@ROM.USNO.NAVY.MIL Subject: Re: The real problem with leap seconds Message-Id: [EMAIL PROTECTED] References: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: [EMAIL PROTECTED] User-Agent: Mutt/1.4.2.1i Sender: [EMAIL PROTECTED] Precedence: list Status: RO 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 -- Steve Allen [EMAIL PROTECTED]WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m From [EMAIL PROTECTED] Sat Jan 7 12:28:40 2006 Received: from juno.usno.navy.mil (HELO [198.116.61.253]) ([198.116.61.253]) by ivan.Harhan.ORG (5.61.1.3/1.36) id AA14637; Sat, 7 Jan 06 12:28:38 GMT Received: from rom.usno.navy.mil by [198.116.61.253] via smtpd (for ivan.Harhan.ORG [208.221.139.1]) with SMTP; 7 Jan 2006 12:36:23 UT Received: from ROM (rom.usno.navy.mil [10.1.4.27]) by rom.usno.navy.mil (8.12.8/8.12.8) with ESMTP id k07BLaki031306; Sat, 7 Jan 2006 12:28:29 GMT Received: from ROM.USNO.NAVY.MIL by ROM.USNO.NAVY.MIL (LISTSERV-TCP/IP release 1.8e) with spool id 0583 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 12:28:28 + Received: from TS-FW.usno.navy.mil (TS-FW.usno.navy.mil [10.1.1.3]) by rom.usno.navy.mil (8.12.8/8.12.8) with SMTP id k07CSRkM032500 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 12:28:28 GMT Received: from mail.metronet.co.uk ([213.162.97.75]) by TS-FW.usno.navy.mil via smtpd (for rom.usno.navy.mil [10.1.4.27]) with SMTP; 7 Jan 2006 12:36:12 UT Received: from [192.168.26.3] (213-162-103-78.edmund434.adsl.metronet.co.uk [213.162.103.78]) by smtp.metronet.co.uk (MetroNet Mail) with ESMTP id 72B0F408240 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 12:28:18 + (GMT) Message-Id: [EMAIL PROTECTED] Date: Sat, 07 Jan 2006 12:28:20 + From: Ed Davies [EMAIL PROTECTED] User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en Mime-Version: 1.0 To: Leap Seconds Issues LEAPSECS@ROM.USNO.NAVY.MIL Subject: Re: [LEAPSECS] The real problem with leap seconds References: [EMAIL PROTECTED] [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: [EMAIL PROTECTED] Precedence: list Status: RO Steve
Re: The real problem with leap seconds
Please ignore this post. It got away because I was connected to my UNIX host from my girlfriend's PC over her cable Internet connection which is probably the crappiest in the world as I was composing a reply to some posts on this list, and as it crapped out on me, the mail process on the UNIX host terminated and sent out whatever garbage was in its compose buffer. MS
Re: The real problem with leap seconds
Steve Allen [EMAIL PROTECTED] wrote: If I read it right you have reinvented Markus Kuhn's UTS [...] Close to it, but... Ed Davies [EMAIL PROTECTED] followed up: Also, Markus wasn't proposing UTS as a civil timescale but just for use within computer systems, etc. Therein lies the key difference. I have strived to make my argument as independent of computers as I could. To me the need for a real number time scale is necessitated more by philosophy than computer science, which is why I have resorted so much to the mathematical abstraction of a real number in my paper. My central argument still stands that current UTC is unsuitable for the *philosophical* application of defining the abstract ideal scale of civil time since it is not a scale in the mathematical definition of this term (a real number). I believe that the scale of civil time needs to be a scale. Furthermore, I believe that it should be related to the cycle of day and night rather than completely decoupled from it, so I won't support freezing the leap seconds for the next few centuries as a solution. That leaves me with my current position of arguing for a coordinated time scale with elongated and shortened seconds. MS
Re: The real problem with leap seconds
Poul-Henning Kamp [EMAIL PROTECTED] wrote: In this rather humorous document you have managed to say that POSIX screwed up badly. We already knew that :-) What does this have to do with POSIX? The word POSIX does not appear in my article. MS
Re: The real problem with leap seconds
Ed Davies [EMAIL PROTECTED] wrote: 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 [...] You have dodged the problem so conveniently! Of course I know how to convert UTC to TAI or vice-versa, but that is not the problem statement at hand. The problem statement at hand is to express UTC *itself* as a real number, rather than convert it to some other time scale. For UTC itself must be expressible as a real number in order to be called a time *scale*. If you admit that this cannot be done, then you should revise TF.460-6 to remove all use of the word scale and openly admit to UTC being a time non-scale. Then no one will use UTC as the civil time scale since it'll be obvious that as a non-scale it is not suitable as a scale of any kind. I stand by my assertion that the current ITU-R spec for UTC (and its previous CCIR versions) is a clever scam, a parlor trick designed to sell a non-scale to civil philosophers wanting a SCALE of civil time. The manner in which it was adopted in 1970 by CCIR, a shove-down-the- throat move reminiscent of the current leap hour scheme, does not help them look any better. MS
