[LEAPSECS] stale leap second information

[Steve Allen]

On Mon 2015-01-12T12:14:22 -0800, Steve Allen hath writ:
> The new version which is in github reads
>
> #       Updated through IERS Bulletin C49
> #       File expires on:  28 December 2015
> #
> #@      3660249600

but also, the new version of the NIST leap-seconds.list file which
is included in the github repository adds this new text

#      Some systems implement leap seconds by amortizing the leap second
#      over the last few minutes of the day. The frequency of the local
#      clock is decreased (or increased) to realize the positive (or
#      negative) leap second. This method removes the time step described
#      above. Although the long-term behavior of the time scale is correct
#      in this case, this method introduces an error during the adjustment
#      period both in time and in frequency with respect to the official
#      defintion of UTC.

I will not be surprised to be informed that this new text is motivated
by the Google "leap smear".  This is the sort of "I disapprove of the
way that you interpret UTC" attitude and language which has been
evident in way too many of the documents ever since the inception of
what we call UTC.

I think it is imperative that the result of this 15 year process is a
set of time scales that everybody agrees to use in the same way.
As things stand the thing which we know as "UTC" continues to look
like a 50 year old flame war with no progress toward a consensual
resolution.  That doesn't happen with GPS system time, nor with TAI
as implemented by devices using IEEE 1588.  Those things work.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165    Lat  +36.99855
1156 High Street            Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m