23 hrs
volsano
One Y2K remediation I worked on had systems from the 1960s -- crucial systems that ran the whole show.

We easily (for some definitions of the word) fixed their 1980s and 1990s stuff that used 2-digit years.

But we did not touch the 1960s and 1970s stuff that had a specialised date storage format. It was 16-bit dates. 7 bits for year. 9 bits for day of year.

It was too assemblery, too unstructured, too ancient.

And, anyway, 9-bit year counting from 1900 (as they did) was good until the unimaginably far future.

The unimaginably far future is nearly with us: 1900 + 127 = 2027.

I am waiting for the phone to ring so I can apologise, - and quote them an unimaginably large number to finish the job.

David 132Silver badge
Happy
"Worst prank ever"?

at least for a few moments, because the phone soon rang.

"It was the Australian office, laughing their heads off..."

Ah, what they should have done, instead of just hanging up the phone at local midnight, is babble something incoherent about "my god... the koalas... wallabies... they've got machetes... oh the humanity... oh nooooo, the 'roos have taken Clyde..."

And then hung up the phone. //

jakeSilver badge
My y2k horror story.
I sat in a lonely office in Redwood City for a couple hours before and after midnight, playing with Net Hack[0]. My phone didn't ring once. As expected.

The cold, hard reality is that I and several hundred thousand (a couple million? Dunno.) other computer people worked on "the Y2K problem" for well over 20 years, on and off. Come the morning of January 1st, 2000 damn near everything worked as intended ... thus causing brilliant minds to conclude that it was never a problem to begin with.

HOWever, in the 2 years leading up to 2000, I got paid an awful lot of money re-certifying stuff that I had already certified to be Y2K compliant some 10-20 years earlier. Same for the embedded guys & gals. By the time 2000 came around, most of the hard work was close to a decade in the past ... the re-certification was pure management bullshit, so they could be seen as doing something ... anything! ... useful during the beginning of the dot-bomb bubble bursting.

[0] Not playing the game, rather playing with the game. Specifically modifying the source to add some stuff for a friend. //

Anonymous John
FAIL
Y2.003K
The government dept I worked had a flawless Y2K. Until a software update three years later. A drop down year menu went

2004

2003

2002

2001

1900

Quite an achievement for seven year old software that used four digit years from the start.

Now let's meet a reader we'll Regomize as "Rob" who at the time of Y2K worked for Sun Microsystems in the UK.

As a global company, Sun had an early warning system for any Y2K problems: Its Australian office was 11 hours ahead of the UK office, so if any problems struck there, the company would get advance notice.

Which is why, as midnight neared Down Under, Rob's boss called Sun's Sydney office … then heard the phone line go terrifyingly silent as the clock ticked pas midnight. Rob said that "scared the hell out of my manager" – at least for a few moments, because the phone soon rang.

"It was the Australian office, laughing their heads off," Rob told On Call. ®

Alan J. Wylie

VMS got it right

VMS (since 1977) has stored time as 100ns clock ticks since 17 November 1858 (the start of the Reduced Julian Day (an astronomical timescale, the "reduced" variant was introduced by the Smithsonian Astrophysical Observatory in 1957 to record the orbit of Sputnik). It will run out of bits in the year 31,086.

Evil Auditor

Re: VMS got it right
...and about 29,000 years from now, someone will have discovered an ancient calculation machine and will have figured out how it worked. And they will see that its clock stops in the year 31,086. And some of them will start a cult that believes the end is near for an ancient civilisation allowed their calender to run until then...

Phil O'SophicalSilver badge

Re: VMS got it right

VMS got most things right.

There is, though, a well-known bug filed against VMS for a related issue. The standard message display only permits 4-digit years, so even if the clock is fine until 31,086 there will be a display error when it ticks over on Dec 31st 9999. Last time I saw that bug in the DEC tracking system it was in an 'accepted' state, with a note that it will be fixed "in a future major architecture". Sadly unlikely now...

Feeling old yet? Let the Reg ruin your day for you. We are now substantially closer to the 2038 problem (5,849 days) than it has been since the Year 2000 problem (yep, 8,049 days since Y2K).

Why do we mention it? Well, thanks to keen-eyed Reg reader Calum Morrison, we've spotted a bit of the former, and a hint of what lies beneath the Beeb's digital presence, when he sent in a snapshot that implies Old Auntie might be using a 32-bit Linux in iPlayer, and something with a kernel older than Linux 5.10, too.

That 2020 kernel release was the first able to serve as a base for a 32-bit system designed to run beyond 03:14:07 UTC on 19 January 2038. //

Like Y2K, it's easy to explain and fairly easy to fix: traditionally, UNIX stored the time as the number of seconds since January 1, 1970 ­– but they held it in a signed 32-bit value. That means that at seven seconds after pi o'clock in the morning of January 18th, 2038 (UTC), when it will be 2,147,483,647 (2³¹) seconds after the "epoch", the next time will be -2³¹: 20:45:52 in the evening of December 13th, 1901.

It has already been fixed in Linux and any other recent UNIX-ish OSes. The easy way is to move to a 64-bit value, giving a range of 292 billion years either way. That'll do, pig.

The fun bit is finding all the places it might occur, like this fun (and old and long-fixed) MongoDB bug. MongoDB stores the date correctly, Python stores the date correctly, but dates were passed from one to the other using a 32-bit value.

vtcodger

Re: Attitude problem
YOU may have spent New Years Eve 2000 at a great party. I and many others I'm sure, spent New Years morning,2000 booting 100-plus PCs to make sure they at least sort of worked -- never a certainty with Windows-98 even on normal mornings.

MiguelC

Re: Attitude problem
I was on duty that evening. At midnight we nodded, saluted each other, and went to work checking everything was running smoothly. Having had no alerts whatsoever, at around 1AM I went to the nearest ATM and checked my balance and latest account movements (an account in another bank than the one I was working for at the time). There was an interest credit of around the equivalent of 3000€. Resisting the urge to spend it there and then, I went back, showed the slip to my co-workers and pondered on what would happen from there on. At 8 AM, after an uneventful night on the job, I went down and checked my balance again. Without a trace of that earlier payment, it now showed the correct and, unfortunately, much smaller interest deposit...

Someone's night was indeed a lot more eventful than mine ;) //

Bill GraySilver badge
Reply Icon
Re: The bug is in the support library code (libc?) of a 1982 C compiler?

I suspect most time library code of this vintage also omits the year 2000 leap year (as I recall SGI Indigo Irix 4 did) and would be a day out after 2000.02.28.

I dunno how common that particular error would be? To screw things up that way, you have to simultaneously know that (in the Gregorian calendar) "century" years are not leap years, but also not know that years evenly divisible by 400 are leap years. That is to say, you have to be a little ignorant, but not completely ignorant.

If you're completely ignorant of the problem, you'll say that 2000 should have a leap day, and be correct for the wrong reasons.

Museum boffins find code that crashes in 2037

A stark warning about the upcoming Epochalypse, also known as the "Year 2038 problem," has come from the past, as National Museum Of Computing system restorers have discovered an unsetting issue while working on ancient systems.

Robin Downs, a volunteer who was recently involved in an exhibition of Digital Equipment Corporation (DEC) gear at the museum, was on hand to demonstrate the problem to The Register in the museum's Large Systems Gallery, which now houses a running PDP-11/73. //

"So we found bugs that exist, pre-2038, in writing this that we didn't know about."

The Year 2038 problem occurs in systems that store Unix time – the number of seconds since the Unix epoch (00:00:00 UTC on January 1, 1970) in a signed 32-bit integer (64-bit is one modern approach, but legacy systems have a habit of lingering).

At 03:14:07 UTC on January 19, 2038, the second counter will overflow. In theory, this will result in a time and date being returned before the epoch – 20:45:52 UTC on December 13, 1901, but that didn't happen for Downs. //

zb42
As the article is specifically about date problems that occur before the 32bit unix time rollover, I think it should be mentioned that:

32bit NTP is going to roll over on the 7th of February 2036.