Re: [LEAPSECS] making leap hours workable

From: Ed Davies <ls_at_edavies.nildram.co.uk>
Date: Thu, 03 Jul 2003 15:13:55 +0100

Markus Kuhn wrote:
> ... because it
> seems inconvenient as long as politicians worldwide can't agree on
> common dates of switching between summer and winter time. ...

Well, would you vote for a politician who would agree to ending
summer time on the same day over thw whole world - both northern
and southern hemispheres?

More seriously, I'm not sure why a common date is required. First
there's a discontinuity in TI, say at midnight December 31st/
January 1st, resulting in an instaneous change in the offsets of
all the timezones around the world - they remain continuous at this
point. Then, at convenient times during the year the timezones
adjust so that, by the end of the year, they are back at their
original offsets. Obviously it would be nice if they did this
together but it's not essential. I guess timezones which don't
normally implement daylight saving might choose to change at
the same time that neighbours which do change.

---------------------------------------------------------------

I realise that this is something of a "what if..." conversation
by people who are not overly impressed with the ITU proposals
but I'd just like to poke in my view that I think this idea of
dropping leap seconds in about 20 years and replacing them with
leap hours is just about the worst possible "solution":

  - For the next 20 years we'll be stuck with leap seconds but
    it'll be even harder than now to get people to take the
    matter seriously because they'll be going away anyway.

  - Our generations have dumped enough physical rubbish on the
    future without leaving this "timebomb" in the paperwork, too.

My humble opinion is that in 1972 leap milliseconds should have
been introduced (i.e., set the UTC day length to an integer number
of milliseconds, e.g, 86 400.002 seconds, announced well in
advance like the current leap seconds) instead of leap seconds.
99% of people can safely ignore leap seconds and 99% of those
left could ignore leap milliseconds (e.g., users of the currently
broadcast DUT1 to 0.1s precision) leaving only a few left to
really worry. The only snag I can see with leap milliseconds
would be the "glitch" in the time signal as a frequency
standard over 00:00:00Z - which it would be easy to cancel out
because presumably the UTC LOD would be broadcast, probably
in the bit positions currently used for DUT1.

The big advantage of leap milliseconds is that they would happen
often - not like leap seconds which happen so rarely that they
might not appear at all in the development cycle of many systems.

However, I think there would be a real outcry if an attempt to
change to leap milliseconds were to be made now.

We've got leap seconds and will have to live with them for a good
few years yet. We might as well concentrate on doing this
methodically rather than trying to "fix" the problem by storing
up a bigger problem for the future. There is probably no
significant difference between a "short term" solution which works
for the next 20 years and a long term solution which obviates any
supposed need for change.

Ed.
Received on Thu Jul 03 2003 - 07:16:23 PDT