Y2K bug – A surprisingly old Year 2000 bug has resurfaced in BSD 2.11’s NTPd, triggered on a 1975 PDP-11/70 setup with a specific Traconex time-signal adapter. It produces an “offset excessive” log error tied to explicit 20th-century year numbering—proof that Y2K risks
A Y2K nightmare never came.
That’s what makes the latest rediscovery in BSD 2.11 feel a little haunting. Even after the panic of the turn of the millennium faded into history, one Year 2000-era bug appears to have slipped through—and only shows itself in a very specific setup involving NTPd.
The resurfacing comes via a report by [Van Heusden] on an NTPd bug in BSD 2.11. It’s an obscure flaw. and the conditions for seeing it are just as niche as the system it’s tied to: a PDP-11/70 from 1975. running BSD 2.11. the kind of environment that most people will never touch outside retrocomputing circles.
The demonstration requires connecting a particular adapter by Traconex. That adapter is capable of receiving WWV/WWVH time signals, and the process involves setting it up for use by NTPd before running the command “ntpd -a any -d -d -d -d”.
Once that sequence is in place, the system can generate an “offset excessive” error in the log. The attached patch points to why: explicit 20th-century numbering. In other words. the bug isn’t just about date formatting in a broad. theoretical sense—it’s about how the software assumed something about how years would be represented and handled.
It won’t matter to most modern users. The whole scenario is built around hardware and software from decades ago, and even the report frames the issue as something unlikely to affect anyone today.
Still, the rediscovery lands with a particular kind of punch for anyone who lived through the Y2K era. This isn’t just proof that Y2K failures could hide in two-digit year fields. It’s also evidence that “lazy shortcuts and assumptions” around years were part of the problem—assumptions that could survive well past the crisis point.
There’s also another reason people are paying attention: the Year 2038 problem is now “pretty much right around the corner.” The lesson from a bug that lived on in BSD 2.11 isn’t that society will melt down again. It’s that the same kinds of time-related assumptions can come back in unexpected ways—long after the calendar panic seems like it should have been finished.
Y2K bug BSD 2.11 NTPd PDP-11/70 Traconex WWV WWVH offset excessive year 2038 problem time signals
So this is why my computer time is always off??
I mean Y2K is “over” right? Sounds like they’re just scaring people again. Also who even has a PDP-11/70 in 2026.
Wait the article says it was triggered by a “Traconex time-signal adapter” and the command is ntpd -a any… like that’s super specific but it still somehow proves Y2K risks a nightmare? That seems backwards. If it’s that niche, why are we acting like it could spread. Feels like they’re connecting it to 2038 just for clicks.
“offset excessive”?? That sounds like my paycheck being off by like a day or two. Also Year 2038 problem is right around the corner now, so great, another countdown. I don’t understand any of the PDP-11 stuff, but time bugs always come back, right? Like, computers can’t do years, period. My uncle said the Y2K bug never really went away so this just confirms it.