[LEAPSECS] USWP7A docs for 2013 September meetings

[Redman, Russell]

Ahh, the bracing splash of cold reality!!

Yes, I do recognize the scale of what I am suggesting, but I believe the case is not as clear-cut as that.

Apologies, but for all its undoubted virtues md5crypt is not the most widely deployed piece of software.  That credit surely goes to one of Microsoft Windows, Linux, or Android.  These examples are pertinent because I am not talking about user-installed add-ons.  This is primarily system software, so my target audience would ideally be developers (and their managers) for OS software and time distribution software.  These are te people with the actual power to change the system.  

Nor do I even contemplate total replacement of the OS on every computer on the planet. There are many applications where existing software works well enough and occasional interruptions in service for leap seconds are easily accomodated.  So long as their owners and operators are happy, those systems will continue to run.  I expect there will be legacy systems running for the next several decades at least, and backwards compatability is an important issue for the owners of these systems.  When they are replaced with newer systems, however, the owners should have the option to purchase machines that do not suffer from this particular problem.

I think a useful analogy is for vehicle emission standards.  We will never replace every vehicle that belches out pollution, but we can require that new vehicles have better performance and depend upon the steady replacement of the fleet to ensure that the new standard eventually becomes the norm.  The old clunkers will continue to run until their owners decide that something better is worth the cost.

Just so for improvements in the OS.  Microsoft, Linux and Google all have vested interests in providing software that runs reliably.  If they can supply systems that keep time properly, their applications will run more reliably and will be easier to synchronize over large systems.  Developers will also appreciate an environment in which the system clock ticks at a steady pace, providing a smoothly increasing time with no ireegularities.  This will lower both development costs and operational costs.  

Companies running time-critical applications will switch to newer, more capable systems if and when it makes economic and practical sense to do it.  Right now they have no choice but to purchase systems that do NOT implement UTC correctly, and this forces operational costs on them that they have no ability to avoid.  Certifying the new systems will take time, but reduced operational costs and improved reliability will encourage the replacemnt of these systems over time.

I like market solutions for problems like this.  Give people a choice, and in time they will chose correctly because it is in their own interest to do it.  Right now they do not have that choice.  That is what I am trying to change with this suggestion. 

Nor do I believe, however, that the community of people who will be negatively affected is as small as we might hope.  Forget astronomers for this discussion.  They are competent, well educated people who will adapt their code (reluctently, in an era where everyone's budgets are extremely tight) to whatever decision is made.  I am a complete convert to the idea that professional observatories should fetch the UT1 conversion tables from IERS.  As a working astronomer I am aware that most older observatories are structurally incapable of pointing with an absolute accuracy better than a few arc seconds.  Most of these observatories include observations of pointing sources with known celestial coordinates as part of their standard observing procedures, and newer observatories have active control systems to center the requested source relative to nearby guide stars.  For astronomers, this is a solved problem, except for the money to rework the control systems.

I am more concerned with people and systems that have a hidden dependence on UT1 but do not know it because UTC as currently implemented provides a good approximation to UT1.  These applications are hard to recognize right now because they are not breaking, and their problems will only become apparent slowly, over decades, as the difference between UTC and UT1 grows.  Celestial navigation, particularly as implemented in many legacy safety systems, is an obvious example.  Most of the people who own such systems are scarcely aware they are under threat and will not become aware of the problem until their GPS fails and the backup navigation system steers them out to sea or onto the rocks.

Cheers,
Russell O. Redman



> -----Original Message-----

> From: Poul-Henning Kamp [mailto:phk at phk.freebsd.dk] 

> Sent: Tuesday, August 13, 2013 3:06 PM

> To: Leap Second Discussion List; Redman, Russell

> Subject: Re: [LEAPSECS] USWP7A docs for 2013 September meetings

> 

> In message 

> <4E52262B71749242AFB45D617BA3A8A0B3B325DFC6 at NRCWSTHCM1.NRC.CA>, "Red

> man, Russell" writes:

> 

> >I actually believe (foolish me) that very little new code 

> needs to be written, 

> >but there are always very subtle issues that must be dealt with [...]

> 

> Writing the code is the least part of the task.

> 

> Testing it, although much worse than writing it, is also not 

> the problem.

> 

> Getting over the emotional licensing hangups and the "Not Invented

> Here" syndrome are but minor hurdles.

> 

> Getting people to run the code is for all practical purposes 

> impossible.

> 

> 

> My credentials for this claim is that my "md5crypt" is probably one

> of the most widely deployed pieces of code *ever* and it still did

> not even come close to universal adoption.

> 

> Your idea is simply not going to happen, period.

> 

> Even if you come up with a very concrete and heavy-handed legal

> threat (See: Y2K) most operations will find it cheaper to just

> shut down during the leap-second, than identifying and adapting

> and certifying all their software.

> 

> You are talking recertification of production-lines for medicine,

> control systems for ATC, power-plants, railroads, emergency services,

> sewage treatment and the list just goes on and on and on...

> 

> The world is never going to spend that effort in finite time.

> 

> There are only two realistically possible outcomes:  Leap seconds

> go, and nothing much happens, apart from a handful of astronomers

> needing dental repairs, or leap second stays until they create

> enough havoc to be removed anyway (max 2 centuries)

> 

> Given how hard and expensive leapseconds are to test, there is

> no credible scenario, under which they will be handled correctly

> by default as long as the are sprung on the world with 6 months

> notice.

> 

> The only credible way to get leapseconds handled better, is to

> announce them so far in advance that their handling can be embedded

> in operating systems and the regular software life-/update-cycle

> will get most systems prepared for the lifetime of the software

> release.

> 

> That would require leap-seconds to be announced irevokably

> 5-10 years in advance.

> 

> If you want to keep them, _that_ is the cart you should push.

> 

> -- 

> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20

> phk at FreeBSD.ORG         | TCP/IP since RFC 956

> FreeBSD committer       | BSD since 4.3-tahoe    

> Never attribute to malice what can adequately be explained by 

> incompetence.

>