[LEAPSECS] BBC radio Crowd Science

[Rob Seaman]

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 <leapsecs at leapsecond.com> 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
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20170129/d7aaa431/attachment.html>