Re: [LEAPSECS] Calabretta's 86400 s + epsilon day proposal

From: Mark Calabretta <Mark.Calabretta_at_atnf.CSIRO.AU>
Date: Fri, 31 Jan 2003 15:06:43 +1100

On Thu 2003/01/30 15:39:26 -0000, Markus Kuhn wrote
in a message to: LEAPSECS_at_ROM.USNO.NAVY.MIL

>If you make every UTC day 86400 + epsilon(date) days long, then life
>gets more difficult for people who broadcast standard frequencies such
>as 50.00000000 Hz TV sync signals, because now you can't simply say that
>you start a new TV frame exactly at the start of a new second (with UTC
>you can, even across leap second!).

An interesting point, I don't claim to have any expertise in this area
but can think of several possible answers:

1) If it's not important for such signals to be synchronized with the
   start-of-day (i.e. mean solar day, and I can't see straightaway why
   it would be), then just tie them to TAI.

2) If it is important, then eventually the lengthening length-of-day
   will matter. If the aim is to have an integral number of cycles in
   one mean solar day (again, I can't imagine why) then the simplest
   solution would be to adjust the frequency ever so slightly. This
   could either go up or down so that up to 10ms was added or subtracted
   (half the 50Hz period). The relative frequency change is 10ms in
   86400+Epsilon, where Epsilon only increases, i.e. less then 1 part
   in 8,640,000.

> Note that the vast majority of
>critical frequencies we have are an integer number of hertz. It is very
>convenient to adjust these by triggering an oscilloscope from the 1
>pulse-per-second output of an atomic clock or time signal receiver and
>then observe the phase wander of your oscillator. Such adjustments would
>break down if UTC clocks would start to have now 1 pulse-per-(something
>that is an SI second most of the time).

>From point (1) above, there would be a predictable glitch once per day -
it doesn't seem too bad to me.

>From point (2) above, the phase drift would be at most 180 degrees
per 86400s, or 0.125 deg per min.

>Even if, a procedure would still have to be put into place to define the
>function epsilon(date). How long in advance would IERS have to announce
>this function?

Yes, the current leap-second machinery could easily be adapted. Epsilon
updates would not be as frequent as the current leap-second announcements.
However, as I mentioned originally, if non-secular variations in the
Earth's rotation were ignored, thus potentially allowing UT1 and UTC
to depart by several seconds over short periods (which I personally think
is reasonable), then Epsilon would be predictable because the Earth's
secular deceleration is accurately known.

>If I understood you correctly, all you propose is to replace the full
>leap second at the end of a day every few years by a couple of leap
>microseconds at the end of the every UTC day, right? That sounds

A couple of thousand leap-microseconds, right. This is what the
insertion of Epsilon = 2000us would look like (500us ticks), conventional
view on the left and my preferred, but equivalent view on the right:

       UTC UTC

   23:59:59.999000 23:59:59.999000
   23:59:59.999500 23:59:59.999500
   23:59:60.000000 24:00:00.000000 <- Epsilon insertion begins
   23:59:60.000500 24:00:00.000500
   23:59:60.001000 24:00:00.001000
   23:59:60.001500 24:00:00.001500
   00:00:00.000000 00:00:00.000000 <- Epsilon insertion ends
   00:00:00.000000 00:00:00.000500

>slightly more complicated to me and doesn't fundamentally eliminate the
>problem that there still will exist UTC time stamps after 23:59:59.9999999...

It does eliminate several fundamental problems, as originally listed,
and introduce others which are not so fundamental, as originally listed.
On balance, I think the wins exceed the losses, and I am thinking
particularly of the longer term. I don't see that it matters that UTC
timestamps might exceed 24:00:00.

>You could alternatively stretch the length of the UTC second at the end
>of each day, and this way your proposal would be similar to UTS, except
>that you make the correction every day whereas I prefer to limit it to
>the vicinity of each current UTC leap second. But pulse-per-second
>signals would experience a phase jump at the end of every day ... :-(

UTS seems like a practical solution, or perhaps "bandaid" might be a
better description, for systems which don't handle leap-seconds properly.
Given that at least some of us don't want to see any changes made to
UTC in the short term I would endorse it as an interim fix for such
systems.

Mark Calabretta
ATNF
Received on Thu Jan 30 2003 - 20:07:09 PST