A year before the arrival of the brand-new 21st century, the Year 2000 Bug was predicted to grind modern society to a halt and ensure that at the dawn of the year 2001, there’d be nothing left but the smoldering wreck of once great societies. Thanks to the concerted efforts of countless engineers, software developers, and many others, we were left with mostly just silly glitches, with one of these surviving bugs apparently just discovered, as [Van Heusden] reported on an NTPd bug in BSD 2.11.
To be fair, it is a pretty obscure one, as the demonstration involves BSD 2.11 on a PDP-11/70 from 1975, so it’s probably not something that still sees much use outside retrocomputing enthusiast circles. In the blog post, the demonstration involves connecting a specific adapter by Traconex, capable of receiving WWV/WWVH time signals, and setting it up for use by the NTPd prior to running the ntpd -a any -d -d -d -d command.
This can create an ‘offset excessive’ error in the log, which, as the attached patch shows, is due to the use of explicit 20th-century numbering. Although not a bug that’ll really affect anyone, it shows that Y2K bugs didn’t just hide in two-digit year fields, but also lazy shortcuts and assumptions when handling years. This will be useful information while we try to avoid society melting down once more, as the Year 2038 problem is now pretty much right around the corner.
There’s another roll-over event you’ve overlooked: NTP itself uses a 32-bit unsigned counter with an epoch of 1900. It rolls over every 136 years.
The 2030s will be interesting!
NTPd has supported “Era” rollover since about 2010, so for most of the world the unsigned int rolls over to zero, the era increments by 1, and the 70 offset is automatically adjusted for.
The BSD 2.11 version might be affected. The rest of us not really.
I say “might” only because I can’t find a version number on the thing. The patch here only patches a single device that used to be built-in to ntpd.
(Personally I thought WWV had already stopped broadcasting, today I learned)
I think you mean 2000. Unless there’s a zero point I’m not aware of. ;)
“the Year 2000 Bug was predicted to grind modern society to a halt and ensure that at the dawn of the year 2001, there’d be nothing left”
Shouldn’t that be at the dawn of 2000?
Yes, it should. But who cares.
Maybe the Y2K big was the last chance to stop AGI take over humanity and the world. Before everything got too interconnected to shut down.
Eh, before everything became too interconnected to successfully maintain.
Khutting it down is easy; there are so many critical fragile points.
Keeping it working is much more challenging.
The Y2K big/bug was certainly big for us computer contractors!
It’d presumably take at least a few months for the carnage to really take effect :)
Really needs the first part of sentence to see the reason. I guess it was a sneak in that 2000 was the end of the last millennium, and century.
“A year before the arrival of the brand-new 21st millennium”…”ensure that at the dawn of the year 2001, there’d be nothing left but the smoldering wreck of once great societies. ”
So, the Y2K rectification work prevented the first year of the new millennium in 2001, occuring in a dystopian horror rather than BAU.
(That dystopian horror was to come a few decades later)
And replying to self, that I just noticed it should be 21st century and 2nd Millennium.
21st millennium would put us out way past human extinction into the era where the slime-mold of AI slop spreads – without any humans remaining – into the furthest corners of the universe.
technically its the 3d millennium. sorry i had to be pedantic a second time.
and a third time because i left an r out of 3rd.
You are completely correct I went off by one as well. :D
Homer-esque Doh!
Genuine thanks :D
Like the leap year bug in 1976. The OS would not let the users enter the date of February 29. True story. DMFII on the Singer System Ten.
21st millennium? its not the year 21026.
besides its my turn to be pedantic.
I worked for SGI during Y2K. The first day of the new year all our cron jobs were running twice. We contacted the SGI operating system engineers. They came back with a solution. Wait a day. Next day and everything had returned to normal.
I recall there were several of these bugs reported on in 1999 listing various problematic dates for different systems. We had a spreadsheet of all our systems at the Mill i worked at. They ranged from the 2030s and others where in the 3060s