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