Forgot your password?
typodupeerror
This discussion has been archived. No new comments can be posted.

NTP Glitch Reverts Clocks Back To 2000

Comments Filter:
  • Re:Not an NTP glitch (Score:4, Interesting)

    by Guspaz (556486) on Tuesday November 20, 2012 @05:18PM (#42046727)

    And end-user systems certainly don't accept that large a skew. ntpd on end-user systems would just have been unable to sync their time while the servers were affected.

  • by Anonymous Coward on Tuesday November 20, 2012 @05:19PM (#42046731)

    NTP -- at least, the formal Unix client -- already has checks in place to reject huge clock skews like this.

    The failure, of course, was dipshit Windows clients talking directly to low-strata servers. And then blindly accepting such a massive skew. Good jorb there, Microsoft, as always.

  • by DamonHD (794830) <d@hd.org> on Tuesday November 20, 2012 @05:22PM (#42046773) Homepage

    Generally xntpd and its ilk will not step the time more than a small amount, but will rather give up and quit instead. One machine such as (say) the RPi with no RTC that use ntpdate to *set* rather than *adjust* the clock, this is harder to avoid, but servers should not be automatically running ntpdate when configured properly.

    So there may be *two* bugs here to get the problem: one in an NTP implementation and one in use of ntpdate for anything other than manual updates on servers. But I haven't read TFA yet.

    (On the little bit of work I put into the ARCRON driver I inserted extra code to look out for year rolls, etc, on top of whatever xntpd would do. In part because ARCRON only sends 2-year dates IIRC.)

    Rgds

    Damon

  • by ShanghaiBill (739463) on Tuesday November 20, 2012 @05:34PM (#42046957)

    Why do people keep pretending that it wasn't? It was a real issue, that required real work to fix. If none of that work had happened, it would've hit and it would've hit hard.

    Lots of organizations worked hard to prepare for Y2K. Lots of other organizations did absolutely nothing to prepare. Neither had any significant problems on 1/1/2000. The reason is there were very few problems to begin with. The myth was that back when memory was precious, programmers stored the year in two bytes instead of four. But those of us that actually programmed in the days when 4K was a LOT of RAM, know that we never used two ASCII chars to store a year. We used a single byte to store the offset from 1900 in binary. So there will be no overflow until 2156.

  • by Anonymous Coward on Tuesday November 20, 2012 @05:48PM (#42047173)

    Lots of organizations worked hard to prepare for Y2K. Lots of other organizations did absolutely nothing to prepare. Neither had any significant problems on 1/1/2000. The reason is there were very few problems to begin with. The myth was that back when memory was precious, programmers stored the year in two bytes instead of four.

    While I'm sure plenty of organizations did nothing and were fine, I know for a fact that storing years as two bytes was not a myth. At my organization I fixed such a problem in critical systems. We would have had people collecting GPS data in the field with no way to verify it's quality if I hadn't. Not doom for our organization, but not a "myth" as you call it.

  • by BobNET (119675) on Tuesday November 20, 2012 @05:57PM (#42047329)

    We used a single byte to store the offset from 1900 in binary.

    Most TRS-80 operating systems figured 3 bits was enough [trs-80.org] to store an offset from 1980, so we've already lived through the Y1.988k bug.

  • Re:Not an NTP glitch (Score:2, Interesting)

    by Anonymous Coward on Tuesday November 20, 2012 @06:28PM (#42047797)

    Well... My "out of the box" (ie. no special tweaking) Linux on my laptop did accept it...
    I had to remove tick & tock.usno.navy.mil from my NTP config.

  • by girlinatrainingbra (2738457) on Tuesday November 20, 2012 @07:20PM (#42048513)
    Actually, most TRS-80 operating systems didn't even keep TRACK of time. It's the Disk Operating System (LDOS) that you're talking about. The TRS-80 didn't even have a built in clock / timer board / dedicated bits or bytes for knowing the time. And Level I and Level II Basic on it don't ask about the time or save it on the cassette tape system. And neither did the Apple ][+. You had to buy add-in clock boards to keep track of the time.
    Even the IBM PC did not have a real-time clock [wikipedia.org] until the IBM-AT version [wikipedia.org] in 1984. [Thank you wikipedia for prior info]. If you boot up an old IBM machine, one of the first things that the system asks after boot-up is to enter the time and date. [actual info from turning the old computers on in the garage].

What this country needs is a dime that will buy a good five-cent bagel.

Working...