[LEAPSECS] leap second roundup 2017

[Rob Seaman]

See below.


On 10/23/17 6:28 AM, John Sauter wrote:
> On Sun, 2017-10-22 at 23:46 -0600, Warner Losh wrote:
>>
>> On Sun, Oct 22, 2017 at 11:02 PM, John Sauter <John_Sauter at systemeyes
>> computerstore.com> wrote:
>>> On Sun, 2017-10-22 at 17:53 -0700, Steve Allen wrote:
>>>> The BIPM has contributed
>>>> CGPM draft Resolution "On the definition of Time-Scales"
>>>> For two years various meetings have indicated that a document
>>> like
>>>> this was under construction, so this is probably that result.
>>>>
>>>> A draft of the document seems to be at
>>>> http://www.iaufs.org/CCTF%20Recommendation-DRAFT.pdf
>>>> It largely seems to be a formal way for the CGPM to update the
>>>> definition of TAI and UTC to match what the IAU did over a decade
>>>> ago.
>>>> Unsurprisingly it makes no mention of the connection between the
>>>> calendar day and UT1.
>>> The next-to-last bullet point under "clarifies that" states that
>>> "UTC
>>> is also a means of dissemination of the standard of frequency;
>>> however
>>> this function is limited to intervals that do not contain leap
>>> seconds;".  Why the concern about leap seconds?  As long as you
>>> know
>>> the name of each second, why should it matter that there is a leap
>>> second in the interval?
>> Because one cannot reliably know that. And by reliably, I mean
>> everybody knows, all the software knows, all the software agrees,
>> even among diverse groups whose primary purpose may not be time
>> keeping and may have sloppy habits about leap seconds (eg, the real
>> world).
>>
>> One can know it, sure, but one cannot count on every single other
>> person who touches the data knowing it with certainty. So it's just
>> best to avoid data that spans a leap second.
>>
> By that logic, one should avoid any interval that includes June 30 or
> December 31, since such an interval might include a leap second.
>     John Sauter (John_Sauter at systemeyescomputerstore.com)


By that logic one should avoid intervals spanning the end of February
because of leap days, and avoid any periods in the spring or fall (in
either hemisphere) that might span local DST transitions, or for that
matter that might span DST changes any place one has colleagues, and
avoid doing business with countries that don't adhere strictly to the
Gregorian calendar, and certainly avoid consulting any of the great
majority of clocks on Earth that are not synchronized to UTC.

"It's just best" to recognize that in the real world the word day
implies mean solar time, just as it does on all the other terrestrial
worlds in and out of the solar system. Leap seconds are a means to an
end. Don't like leap seconds? Propose another timescale that doesn't
have them – as was the consensus in Torino in 2003 – or simply buy a
GNSS clock that supports TAI or GPS timescales right now. Leave UTC for
backwards compatibility and stop dancing on the head of a pin.

Multiple timescales exist now for multiple purposes. Multiple timescales
will exist under all scenarios. Debasing Universal Time is not a
solution to any "real world" problem. If you want a new timescale,
define a NEW timescale.

Rob Seaman
Chair, IAU Time Domain Working Group