[LEAPSECS] Coming of age in the solar system

[M. Warner Losh]

In message: <6C773408-836C-4D2A-9D37-0A8B7111E675 at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:

: I've just realized that the archive for the early years of this list

: is offline, otherwise I'd be pointing to discussions about how leap

: seconds are just an issue of representation, about how atomic time

: (an unending sequence of ticks) shouldn't be using sexagesimal at

: all, and about why the SI unit of time should really never have been

: called the "second" in the first place.


And I'd be pointing to those same discussions where actual
practitioners discuss the difficulty in the phrase "just an issue of
representation."  Conceptually it is easy, but so many people get it
wrong, and international standards make it impossible to get it
right.  There's both too much automation in leap seconds, and not
enough.  Nobody cares enough to solve the whole problem, and 'success'
in the software world sadly seems to be defined as 'didn't panic the
OS and eventually it sorted itself out' rather than 'got the time
right around a leap second.'

I've said many times: leap seconds happen to unpredictably to be on
the radar of most people.  They happen too suddenly to always get the
budget they need (nobody likes a mid-year surprise that there will be
a leap second next quarter, so your carefully laid plans go awry).

If they were on a regular schedule, where on the average we tried for
a |DUT1| < 10s, (or 5s or whatever) we'd have a better chance of
getting them right.  Managers would know when to schedule time,
testers would know they could test not just one leap second, but maybe
5 or 10 leap seconds to make sure the software worked.  Software
products could get a longer shelf life.  Sadly, there's no serious
discussion of this middle ground outside of this list.

Of course, it would be cheaper for the software folks to never have to
worry about it again.  That would also make them predictable.

Warner