Is the year 2022. We keep programming in the 1950s
TL;DR: We need to follow one simple rule. Follow the bijection.
The new year arrived with new errors on Microsoft Exchange.
It causes millions of emails worldwide to go undeliverable.
Many of them remain stuck in email transport queues.
Some queues are full and cause entire servers to crash.
The problem
Y2K22 is familiar to engineers like me who worked in Y2K Bug.
Someone abused an incorrect date representation by using something that is not a date.
Exchange's malware scanning engine stores signature dates using 32-bit integers.
Using integers to store dates is a clear bijection violation.
Also a primitive obsession and premature optimization code smell.
The Chain of Responsibilities
Some developer decided (probably without a real benchmark) that storing dates as 32-bit integers was a smart move.
However, The largest possible number that can be stored in 32-bit is 2147483647.
Things were fine for the 2021 dates because it was stamped as 211231XXXX (for 31st December) using YYMMDDhhmm format.
Yet another smell, Date and time are continuous and consecutive measures.
So are integers, but not this absurd representation.
But the developer was not alone.
The peer reviewer stated that it was a very good optimization.
Also, the QA team forgot to make basic boundaries testing using the Zombies technique.
The error
It is January 1st, 2022, according to this bijection we need to convert it to 2201010001.
This is not possible when trying to format it to 32-bits.
The outcome is larger than the maximum number allowed.
This would cause timestamp validations on the server software to fail.
As a result, lots of emails are not being sent piling up on servers.
The fix
Fixing this problem. (It is not a bug) is very difficult.
Exchange is a product running on on-premises servers so it has to be patched manually in many cases.
The manual fix you can execute on your Powershell console is easy
Set the date on the signature file as 2112330001 (December 33rd, 2021)
Yes. it is no joke.
That is the patch.
Violate and abuse the bijection again creating representations of not real entities.
Using this exploit to set this invalid date should also raise an error according to fail fast principle.
Conclusions
If you want to develop serious software and be proud of it, just be loyal to the bijection.
If you create accurate models of your problems your software will always work as expected.
Top comments (2)
I didn't know about this format and this problem.
That is a ridiculous way to store the date-time (as a 32 bit integer). It is an absolutely crazy format.
This is a really interesting (and terrible) problem.
Thanks for writing this up.
Also, if they had only used a 32 bit unsigned integer, I believe the problem wouldn't have occurred (yet) either, right?
How did you learn about that?
I learnt it on reddit.
Storing dates as integers, unsigneds, floats, strings, json whatever leads to the same problem sooner or later.
Dates are Dates
Strings are Strings
People are people
Bank accounts are bank accounts.
Shouldn't be so difficult to understand