For most people, the Y2K bug is a relic of the past. But a glitch in onsite Microsoft Exchange servers brought back memories of the infamous issue as 2022 started.
Let’s look at what happened with this bug and see what we can learn from it.
Y2K22 Explained
When the year rolled over from 2021 to 2022, system admins started to discover that their servers weren’t delivering email as normal. Upon looking into the problem, they found that outgoing mail got stuck in the queue due to the following error:
The FIP-FS “Microsoft” Scan Engine failed to load. PID: 23092, Error Code: 0x80004005. Error Description: Can’t convert “2201010001” to long.
FIP-FS is an antivirus scanning engine that protects mail passing through the server. Exchange checks the date of FIP-FS’s version and stores this date in a signed 32-bit integer (a value that can keep track of both positive and negative numbers) using the YYMMDDhhmm format.
The maximum value of this number is 2,147,483,647. Unfortunately, since January 1, 2022’s value in this format is 2,201,010,001, the check failed and no email was sent.
Thankfully, Microsoft jumped on the problem quickly and issued an automated script fix the next day.
Lessons From Y2K22
This incident addresses the drawbacks of on-premise Exchange servers (versus a hosted solution like Microsoft 365). Every company that uses them for email had to work around this problem for over 24 hours, then apply a fix from Microsoft.
Meanwhile, if a problem like this occurred in Microsoft 365, the company could quickly issue a fix that applied to all users and thus save everyone time. Problems like this are also less likely to occur in cloud software that’s regularly updated, compared to onsite tools that don’t get as much focus these days.
The date format used by this software is not standard. Almost all programming languages have a way to store dates that is much more graceful than converting a string of text to a number. Date-related problems are nothing new for programmers, so hopefully issues like these spur other developers to avoid them in their own work.
Honda’s Y2K22 Bug
It’s not just Microsoft that had a bug related to the year 2022. Many Honda vehicle owners found that their car’s system clocks went back to January 1, 2002, instead of the correct 2022 date, after the new year hit.
My @Honda 2007 CR-V clock now useless in 2022; resets to 2:00 MST on 1/1/2002 after every startup. 32-bit signed integer overflow of yymmddHHMM? Would unsigned int fix it? This is time-critical. 😉 Thousands of us need a software update! pic.twitter.com/BSGCaxnMmx
— Sumner Hushing (@_______shushing) January 4, 2022
It’s not clear what caused this problem. Some people have surmised that it’s an issue with how GPS systems calculate time. They use a 10-bit binary number, which is capable of storing up to 1,024 values, to store the number of weeks that have passed since an epoch (a certain point in time used as the starting point for digital clocks). After that many weeks, the count is supposed to reset to 0.
An affected user found that their GPS clock had gone back to May 19, 2002, which is 1,024 weeks prior to this bug. It’s possible that the code for Honda’s clocks didn’t account for the fact that a GPS rollover would happen on New Year’s Day, making it return to a default value.
A Reddit user shared a response they got from a Honda customer service representative, stating that the problem may persist until August 2022, at which point it will “auto-correct”. Hopefully, Honda issues a fix for this sooner than that.
Dates and Times Are Complex
It might sound silly that an error we worried about over 20 years ago has cropped up again today, when we’re much more technologically advanced. But keeping track of dates and times is a difficult process that programmers have struggled with for years.
Thankfully, neither of these issues were as major as 2021’s worst vulnerabilities, like the Log4j issue. But it’s still interesting to look at what happened and learn from it.