Re: Introduction of long term scheduling
On 2007-01-03, Poul-Henning Kamp commented on Bulletin D 94: > That's an interesting piece of data in our endless discussions about > how important DUT1 really is... So it appears that DUT1, an approximation of UT1 - UTC, is not of much use, even though it is disseminated with many time signals. On the other hand, POSIX implementors need the values of DTAI = TAI - UTC, the count of leap seconds, at least for those UTC timestamps in the future as may occur during the operation of the system. This leads me to my question: would it be helpful for POSIX implementors if each and every UTC timestamp came with the corresponding value of DTAI attached (instead of DUT1)? Would this even obviate the need for a leap seconds table? I realise that this would require changes or extensions to the time interfaces of POSIX (eg, a "time_t" value alone could no longer encode a complete timestamp). My question is just whether such timestamps, indicating both UTC as time-of-day and TAI as "interval time", could be a viable alternative to the frequent updates of leap second tables. Michael Deckers
Re: Mechanism to provide tai-utc.dat locally
On 2006-12-09, Clive D.W. Feather challenged, and I couldn't resist:
> For something more challenging, try the 8 Bank Holidays in England:
>
> ...
> (8) Second weekday after 24th December.
second weekday after 24th December in Gregorian year( Y )
= Gregorian calendar( Y, December, 26 )
+ 2·(floor( D / 5 )) d - (floor( D / 7 )) d
where
D = day of the week number of Gregorian calendar( Y, December, 25 )
(as in ISO 8601 with values in {1..7} and 1 for Monday)
= 1 + ((floor(Y/100) mod 4)·5 + (Y mod 100)·3 - (Y mod 4)·2) mod 7
Sorry for being off-topic.
Michael Deckers
Re: Accommodating both camps
Poul-Henning Kamp wrote on 2006-01-25: > If we abandon leapseconds today to avoid getting computer problems, > we still have several hundred years of time to decide how to > deal with any long term effects. I do not think so. When civil time is no longer connected to solar time (which is more than abandoning leap seconds!), then this affects legal and cultural issues all over the world, and a difference of a minute or so may well be relevant. Such a difference can accrue in 60 or 80 years. I am not just thinking of lawyers trying to exploit the difference between legal time in Britain (which is GMT) and the time scale disseminated by the NPL. What I find much more disquieting is first, that some problems may become apparent only very late, when the difference between TI and UT is large enough, and, secondly, that it appears to be very difficult to say which areas of daily life will be affected. On the other hand, I believe that most if not all of these problems will not be life-threatening -- whereas many of the problems with leap seconds and computers may well be. So this, rather than other technical merit may finally decide the question. But again, giving up leap seconds in UTC is not the same as accepting atomic time as civil time. Michael Deckers
Re: Accommodating both camps
Warner Losh wrote: > Here's why I'm in camp #2: ... All your arguments are sound and convincing -- current UTC is causing many problems, and I certainly do not want a leap second to happen while I am undergoing open heart surgery. But is TI really better? Celestial navigation can also be life-critical, and solar time is engrained since millenia in so many legal and cultural conventions that it is hard to estimate the cost of adopting a civil time that no longer follows the Sun. I do not know which camp to join! And not to forget, there is also a risk in changing the scheme -- I do not want to undergo open heart surgery while the leap second scheme is abolished or changed (if I live as long). Michael Deckers
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
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 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
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
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: Monsters from the id
John Cowan wrote: [If TAI - 33 s were taken as the new basis for civil timescales, then] > It is UTC that would be eliminated as the basis for local time. It could > be maintained for such other purposes as anyone might have. Yes, the IERS could maintain it as the timescale for a timezone whose local time approximates UT1 up to a second. Michael Deckers
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 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
