4 ms·

> shitty servers as default are better than none No, absolutely not. Defaults that can cause subtle errors are worse than a program abort with an error message

by ajnin 11y ago

> shitty servers as default are better than none No, absolutely not. Defaults that can cause subtle errors are worse than a program abort with an error message telling you to fill in a configuration value. Especially after reminding that Google servers run "a non standard concept of time" (what does that even mean?). It is not a reasonable default by any stretch of the imagination.

diminishedprime 11y ago
> 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.
- fixermark 11y 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. 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" ;) )
  - lmm 11y 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.
    - fixermark 11y ago
      I stand 100% corrected. And oddly sad. ;)
  - CydeWeys 11y ago
    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.
  - dunham 11y ago
    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.
    - deleted 11y ago
      [deleted]
  - wyldfire 11y ago
    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?
keithpeter 11y ago
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.
AdieuToLogic 11y ago
> 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 http://www.faqs.org/docs/artu/ch01s06.html#id2878548

by ajnin 11y ago

diminishedprime 11y ago

> 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.

fixermark 11y 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. 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" ;) )
- lmm 11y 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.
  - fixermark 11y ago
    I stand 100% corrected. And oddly sad. ;)
- CydeWeys 11y ago
  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.
- dunham 11y ago
  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.
  - deleted 11y ago
    [deleted]
- wyldfire 11y ago
  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?

keithpeter 11y ago

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.

AdieuToLogic 11y ago

> 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 http://www.faqs.org/docs/artu/ch01s06.html#id2878548