> Google servers run "a non standard concept of time" (what does that even mean?).

I know that one way they do this is through using what they call a leap smear instead of a leap second. Yesterday, instead of having 11:59:59 twice, they evenly distributed out the second over the course of the day.

I mean, technically speaking (unless there's an RFC, ISO, or ANSI that I'm unfamiliar with), having the same time twice is also "non-standard." The most correct course of action would be to have an 11:59:60, as per the actual leap-second standard.

The fact that basically no computer system in the world allows for a 61-second minute is just a failing in almost all time libraries to adhere to the standard.

(This is a fancy way of saying "Time is a quagmire and writing code to properly handle time is an exercise in optimizing ulcer generation" ;) )

On Unix, (OSX and I believe Linux, too) the man page for the tm structure specifies that tm_sec ranges from 0-60, so it does support 61 second minutes. I think this has been the case for a while. I recall noticing this years ago.

> I mean, technically speaking (unless there's an RFC, ISO, or ANSI that I'm unfamiliar with), having the same time twice is also "non-standard." The most correct course of action would be to have an 11:59:60, as per the actual leap-second standard.

I believe GP is incorrect (or rather, the overall point that most NTP servers followed the standard and Google's didn't is correct) and most NTP servers did have 11:59:60 as per the standard.

I stand 100% corrected.

And oddly sad. ;)

Leap seconds only date back to 1972. Computer systems, and especially the concept of time in computer systems, are older than that. Time smearing does appear to me to be the best way to compromise between the two worlds. Adopting a 61-second minute full out isn't making any compromises, and not only will it confuse computer systems (including those outside your control that you interoperate with, even if you somehow manage to get yours working perfectly with it), it will confuse PEOPLE.

Even if you waved a magic wand and made all computer systems in the world compatible with 61-second minutes, it'd still cause problems because people aren't going to know what to do with it. Imagine what happens when a non-technically-savvy person comes across a time that looks like 23:59:60.5 on something at their work. They'll immediately think that's some kind of error.

Hmm..what would happen if you were to attempt to write that time to an RTC in that window? I suppose some RTC parts might be designed to reject those writes. Does the RTC interface logic in the OS just not care about leap seconds and therefore misinterprets the time? Or does it need some sort of special correction for this case?

The OA lists some practical issues including a 400ms difference from UT lasting for some days on a regular basis. Depending on the use case for the server being configured, that could be important.

In a wider context have a look at an observational astronomy textbook for the chapter on time systems when you can spare a couple of hours. Its fascinating.

> Defaults that can cause subtle errors are worse than a program abort with an error message

Agreed. I've heard this expressed as "fail fast and fail loud", with a succinct elucidation found here:

http://www.faqs.org/docs/artu/ch01s06.html#id2878548