[glurgh]

This is a genuine question - do you really believe the (to me, seemingly obvious and much greater and potentially more dangerous) costs of switching away from astronomical time for measuring something inherently astronomical like the length of a year are smaller than the costs of removing the occasional time-handling bug in software?

Even in your example, Linux machines didn't actually crash - some processes spinlocked. And it wasn't even all Linux machines, if you were running a mildly old kernel (say, the one that came with debian etch and derivatives) nothing happened whatsoever.

Beyond that, there is no shortage of time standards that are both based on SI seconds and free of leap seconds - Terrestrial Time, International Atomic Time, GPS Time come to mind -

http://en.wikipedia.org/wiki/Terrestrial_Time

http://en.wikipedia.org/wiki/GPS_time#Timekeeping

http://en.wikipedia.org/wiki/International_Atomic_Time

Google's solution is 'leap smear' and they, similarly, did not run into the problem

http://googleblog.blogspot.com/2011/09/time-technology-and-l...

[lmm]

Equally genuine counter: what costs do you see associated with redefining a year as e.g. a fixed number of seconds? To me none are obvious, surely they'd be small compared to what we've already lost from these software bugs.

Leap smear is a good solution, as is TA1; sadly the posix/unix standards do not permit it (which makes it difficult to use on e.g. government projects).

[glurgh]

Well, for one thing a non-constant second seems like it would break just about all of physics in deeply unpleasant ways.

I think 'btilly is right - it's an unpleasantly difficult problem.

I suppose my point is 'it just happens to be unpleasantly hard problem' - given that a great number of specialists have put serious time in thinking about it trying to solve it, I have a very difficult time imagining that the solution (or satisfactory answer) is as simple as 'just blame astronomers'.

Having _two_ or more slightly different units that measure the base unit of time (which would be the case if we defined seconds in terms of (siderial? some other?)) year seems like a far greater potential source of cock-ups than just having a well-defined unit that might not quite, but more often than not, matches astronomical detail.

[lmm]

>I suppose my point is 'it just happens to be unpleasantly hard problem' - given that a great number of specialists have put serious time in thinking about it trying to solve it, I have a very difficult time imagining that the solution (or satisfactory answer) is as simple as 'just blame astronomers'.

As far as I can tell the proposal before the ITU (replace leap seconds with leap hours, with a view to abolishing leap hours once any incompatibilities with national laws have been resolved) solves all the problems quite nicely. I'm not entirely clear why they voted to defer a decision until 2015, but I'm not aware of any serious objections to the proposal.

[btilly]

I'm not aware of any serious objections to the proposal.

The only objections that I've ever heard about are astronomers who are annoyed that this piece of traditional authority is being taken from them. My obviously unsympathetic attitude is that they used to serve an important role, but their once critical role in precision timekeeping has been obsolete since the development of the atomic clock. It is time to recognize that.

[btilly]

This is a genuine question - do you really believe the (to me, seemingly obvious and much greater and potentially more dangerous) costs of switching away from astronomical time for measuring something inherently astronomical like the length of a year are smaller than the costs of removing the occasional time-handling bug in software?

Absolutely.

As http://queue.acm.org/detail.cfm?id=1967009 notes, fear of encountering leap second bugs ALREADY causes many factories to schedule downtime around leap seconds because of how serious the potential consequences of not doing so could be. It is just a question of time until someone who had such a bug doesn't realize it, doesn't schedule downtime, and suffers the consequences.

And what's the consequence of eliminating leap seconds? In the next few decades the Earth and our clocks will drift out of alignment by about 1% of the amount that they are already forced to be out of alignment for most of us by the fact that time zones are an hour wide. Which very few people will notice.

Even in your example, Linux machines didn't actually crash - some processes spinlocked. And it wasn't even all Linux machines, if you were running a mildly old kernel (say, the one that came with debian etch and derivatives) nothing happened whatsoever.

If the bug had been introduced during a longer period without leap seconds - not long ago there was one that lasted 7 years - then its impact would have been more widely felt. And it is true that it wasn't technically a crash, but many websites did suffer outages because internal services stopped responding. In common usage that was a crash.

Beyond that, there is no shortage of time standards that are both based on SI seconds and free of leap seconds - Terrestrial Time, International Atomic Time, GPS Time come to mind...

UTC is the standard for time in C, all languages derived from C (eg Java), and all languages written in C (eg Perl, Python, PHP, etc). It is also the standard in all Unix operating systems (including OS X), POSIX, Linux in all variations including Android, and has even been adopted by Microsoft. It is also the standard in widely used protocols written on top of that, like HTTP, and inside of any software built on top of them, such as web browsers.

Yes, there are other definitions of time that you can use. But UTC as published by NIST and distributed by the NTP utility is "the time" as far as the computer world cares. If you use anything else, people will ask - repeatedly - why you have the wrong time.