Oddbean

@d8402a8b @60d98082 Hmm. I guess you could have isolated a copy of all the network gear - set the time server to 1999/11/31 and run it until Y2K happened to "test" the rollover. On the project I was on, we did all the remediation on our code, got signed statements from all hardware and software suppliers, did roll over tests, and THEN still had a team to shut down all the equipment until Y2K occurred. Sigh.

@e7cebe76 @60d98082 this gear had no date function. it had no time/date clock. most transmission systems were PDH and implemented in hardware. like you, we wrote to all suppliers for certificates of compliance. i don't think we shutdown anything.

@d8402a8b @60d98082 Yeah - that was likely in lower end network gear. I could see some higher end gear would use date/time in some way (say for updates or NTP services). Hey - my favorite one was the request to a company for their Y2K certification for SAND.

@d8402a8b @60d98082 Alas, no. It was one of those - ALL companies must respond with their certification statement about their products being compatible with Y2K. I did a quick search - I can't seem to find an online source for that. I will also note that Y2K problems started in 1995 or so - in credit card processing when the expiration date of the card was 2000 or later. They continue to pop up in 2010, 2020 (y2k+20) where code worked around the problem instead of fixing it too.

@e7cebe76 @60d98082 i still don't believe that. inspired by y2k, i made a y2026 (i think) bug in a lotus notes system i wrote. when year is 2026 it would pop up a dialogue box expressing amazement that this code was still in use and that we had run out of letters of alphabet: A was year 2000 from memory. i was told it was removed when i left.