Leap seconds are a means to an end. It isn’t just astronomers who care about
Earth orientation. Systems for navigation at sea, on land, in the air, and in
space are dependent on the current definition of Coordinated Universal Time as
exactly that, Universal Time, which is to say an approximation to mean solar
time in Greenwich. Risks from leap seconds are discussed every year or two. The
opposite risks from redefining UTC have been explored in the two UTC colloquia:
http://hanksville.org/futureofutc/ <http://hanksville.org/futureofutc/>
Systems engineering best practices will minimize worldwide exposure to both
kinds of risk, and not coincidently will provide the most efficient approach to
trade-offs between costs, implementation schedule, and performance across the
many degrees of freedom of international timekeeping. A good first step would
be to retain the current definition of UTC for backwards compatibility, and if
some deem it necessary, define a new leapless timescale as recommended at the
2003 Torino meeting. Alternately, just use TAI or GPS which are already
commercially available.
Rob Seaman
Lunar and Planetary Laboratory
University of Arizona
—
> On Jan 29, 2017, at 8:33 AM, Michael.Deckers. via LEAPSECS
> <[email protected]> wrote:
>
>
>
> On 2017-01-29 04:48, John Sauter writes about labeling a positive
> leap second 59 as done by Felicitas Arias:
>
>> She prefers to label the leap second as a second 23:59:59, but the UTC
>> definition calls it 23:59:60.
>
> Yes, of course -- I did not want to dispute that.
>
> My point was that Arias' labeling makes it clear that the
> latest discontinuity in TAI - UTC occurred when TAI assumed
> the value 2017-01-01 + 36 s. The ITU labeling (nor any
> other specification in ITU-T TF.460-6) does not imply the precise
> instant of the discontinuity, nor does IERS Bulletin C52.
>
> And about the "danger" of leap seconds through computer
> failures, John Sauter writes:
>
>
>> I would not blame leap seconds but the programmer who did not properly
>> test for leap seconds when developing his software. Leap seconds have
>> been around for over 30 years, so it isn't like they are a new
>> requirement.
>
> Of course you are right -- leap seconds cannot be blamed for computer
> failures, but careless programmers and inconsistent or incomplete
> program specifications may well be.
>
> But my point was not who or what was to blame -- I rather wanted to
> indicate circumstances where even the slowest bureaucracy can
> react swiftly in a very pragmatic manner: if the presence of
> leap seconds might cause harm to human health then their abolition
> is likely. See the introduction of the unit Sv as a special name
> for Gy by the BIPM as an example.
>
> Michael Deckers.
>
> _______________________________________________
> LEAPSECS mailing list
> [email protected]
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
