### Re: Introduction of long term scheduling

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

for being off-topic. Michael Deckers

### Re: Accommodating both camps

the question. But again, giving up leap seconds in UTC is not the same as accepting atomic time as civil time. Michael Deckers

### Re: The real problem with leap seconds

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

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

### Re: The real problem with leap seconds

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

Michael Deckers

### 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

### Re: Monsters from the id

for a timezone whose local time approximates UT1 up to a second. Michael Deckers

### Re: The real problem with leap seconds

, 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

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