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.


Reply via email to