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
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
Internet-Draft on UTC-SLS
A new Internet-Draft with implementation guidelines on how to handle UTC leap seconds in Internet protocols was posted today on the IETF web site: Coordinated Universal Time with Smoothed Leap Seconds (UTC-SLS), Markus Kuhn, 18-Jan-06. (36752 bytes) http://www.ietf.org/internet-drafts/draft-kuhn-leapsecond-00.txt Background information, FAQ, etc.: http://www.cl.cam.ac.uk/~mgk25/time/utc-sls/ Abstract: Coordinated Universal Time (UTC) is the international standard timescale used in many Internet protocols. UTC features occasional single-second adjustments, known as leap seconds. These happen at the end of announced UTC days, in the form of either an extra second 23:59:60 or a missing second 23:59:59. Both events need special consideration in UTC-synchronized systems that represent time as a scalar value. This specification defines UTC-SLS, a minor variation of UTC that lacks leap seconds. Instead, UTC-SLS performs an equivalent smooth adjustment, during which the rate of the clock temporarily changes by 0.1% for 1000 seconds. UTC-SLS is a drop-in replacement for UTC. UTC-SLS can be generated from the same information as UTC. It can be used with any specification that refers to UTC but lacks provisions for leap seconds. UTC-SLS provides a robust and interoperable way for networked UTC- synchronized clocks to handle leap seconds. By providing UTC-SLS instead of UTC to applications, operating systems can free most application and protocol designers from any need to even know about UTC leap seconds. Please have a careful look at the full specification and rationale. Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Indiana time zone change from Department of Transportation
This should provide some more grist for understanding the reality of civil time. This happens pretty often somewhere in the world. A DOT final ruling on Indiana came out today, affecting time zones starting April 2, 2006: http://www.dot.gov/affairs/dot0406.htm Under the Uniform Time Act of 1966, the Secretary of Transportation has the authority to set time-zone boundaries and must base decisions on the convenience of commerce. ... After five months, 22 hours of public hearing testimony and more than 6,000 public comments, the U.S. Department of Transportation today announced a final rule that will change the clock for eight of 17 Indiana counties seeking to move to the Central time zone. ... Seventeen Indiana counties asked the Department last September to change from Eastern to Central time. On Oct. 25, the Department issued a notice proposing Knox, Perry, Pike, St. Joseph and Starke counties move from Eastern to Central time, and made no change to time zones in the remaining 12 counties. ... I heard about this from the time zone mailing list. See e.g. http://www.twinsun.com/tz/tz-link.htm Deborah Goldsmith writes to [EMAIL PROTECTED] about it: Based on my reading of this document, only one zone in tzdata is affected, America/Indiana/Knox. That zone will start observing US Central Time starting April 2, 2006, at the time of the switchover to Daylight Savings Time. Probably the easiest thing to do is to change the last two lines as follows: From: -5:00 - EST 2006 -5:00 US E%sT to: -5:00 - EST 2006 Apr 2 2:00 -5:00 US C%sT Will your computer's time zone databases be up-to-date then? Cheers, Neal McBurnett http://bcn.boulder.co.us/~neal/ Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60
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
