[LEAPSECS] metafilter followup of the leap rant

Joseph Gwinn joegwinn at comcast.net
Thu Jan 2 12:13:10 EST 2014


On Wed, 1 Jan 2014 22:13:30 -0800, Steve Allen wrote:

> folks at metafilter have been discussing the video rant

> about programming time at

> <http://www.metafilter.com/135241/This-way-lies-madness>

>

> Not surprisingly it is more ranting, but near the end is another

> indication of how programmers who do not have to manage real-time

> systems feel about the institution of leap seconds in 1972:

>

> to buggery with all the scientific systems that made the

> obviously unreasonable assumption that any given second is

> exactly as long as any other

>

> This amplifies the impression that also comes from Google's leap smear

> and the recent tendency of Linux distros to prefer chrony to ntpd

> (because chrony allows bigger frequency shifts and avoids leaps).

> To wit, admins of cloud-based, virtualized systems find it more

> expedient to change the duration of seconds than to follow the

> constant-duration seconds in the UTC specification as given by TF.460,

> and so they are doing that.

>

> It remains less clear what sorts of strategies are being adopted by

> admins of systems that must perform real-time operations, for those

> admins are not talking about their coping mechanisms.


In my part of the world (large fixed-site radars), the standard
approach is to define "radar time". It the days before GPS and UTC,
this would be something like a 48-bit integer containing the count of
milliseconds since the birth of Christ, the second (implicitly) having
constant duration. This timescale was uniform and continuous with all
its derivatives, and was defined from 00:00:00 1 January 0001 AD to
something like 8919 AD, which well exceeds the service life of all such
systems.

Nowdays, we still have radar time, but it is more commonly tied to GPS
System Time (not UTC). Again, no leap seconds - too disruptive.

The Air Traffic Control world used to have their own equivalent of
radar time and system time, only loosely tied to UTC, but again there
were no leap-second step discontinuities - the steps were smoothed.

Joe Gwinn


More information about the LEAPSECS mailing list