[ntp:hackers] ITU and Leap second elimination

juergen perlinger juergen.perlinger at t-online.de
Sat Oct 5 10:05:40 UTC 2013


On 10/05/2013 06:08 AM, Mike S wrote:
> On 10/4/2013 12:51 PM, juergen perlinger wrote:
>
>> And are we sure that the leap second smear is something we really need?
>
> Absolutely not. That's an abomination. <snip>  At some point, a
> "smeared" timescale is going to be half a second off from any well
> defined one. A smear is simply an expedient hack.
>
That was my first reaction, too, and I have *not* changed my mind on
that topic.
> The issues with UTC revolve around ignorant assumptions. One cannot
> know when future leap seconds might occur. You can schedule a future
> event to occur at a defined date/time, or you can set it to occur at X
> interval from now, but they're two different things. There can be a
> difference between future absolute and relative times.
I'm fully with you. A lot of technical systems would be better off doing
their work in a single-radix time scale, for various reasons. They
assume they do so, anyway.

Even if a computer could make the necessary astronomical observations to
keep it's clock on UTC autonomously, it could still not predict leap
seconds over longer distances. And so we have clocks that count other
periodic events not related to earth's rotation. Therefore, the
technical measurement process is effectively the same one that is used
for TAI, not for UTC.  UTC simply does not model the physical process
computers use for time measurement.

The really evil thing about using UTC for technical processes is the
fact that it *seems* to work for most of the time, and I guess that's
the root cause for ideas like the leap second smear.  Just curing the
symptoms, not the cause.

Even transitions between daylight savings time and and standard time
have already left a trail of destruction in technical systems, because
the tech spec or standard defined to use local time (shudder) and then
decided not to support anything that would help to disambiguate time
stamps. Have a look at DNP3.0 or IEC870-5-101 (data exchange  protocols
for process control in the energy distribution), just in case you want
to see two standards that caused me a lot of work and headache to deal
with. And IEC61850 (another member of that bunch) has it's own quirks here.

So it seems the ignorance is not limited to programmers.

I accept using UTC for representation as a perfectly legal and sensible
requirement -- in many countries legal time is defined in terms of UTC.
There are a few established ways to indicate something exceptional has
happened, but that's simply a representation layer issue. It's the
misuse as a single-radix time scale for technical processes that causes
all the trouble.

But IMHO removing leap seconds from UTC is attempted cheat and delusion.
Leap seconds are the core of the definition of UTC. since 1972. If you
remove leap seconds from its definition by freezing the difference, you
get effectively TAI+x after the change and the relation to UT0/UT1 is
destroyed. This will create an official successor to UTC at best, and an
informal one at worst.

It's like putting an oxen in front of the cart and hanging a placard on
the horns, reading 'horse'. It does not change the nature of the beast.

Cheers,
    J



More information about the hackers mailing list