We shouldn't blame Microsoft for this; I once worked in the veterinary industry, and one Practice Management System allowed you to register a pet including their real or approximate birth date, or by entering an approximate age.
If you entered a birth date, the software would calculate the pet's age, and we noticed we had the odd quirk, like a 400 year-old cat etc. I couldn't see an obvious pattern to the anomaly, and it didn't occur often, so I created a support ticket.
After a couple of days, I received a response that 'dates were hard' and we should correct the ages manually as needed.
Dates are hard, it's got to be one of the things on the lists of "things programmers don't understand."
Choices to represent dates as an integers (seconds from an epoch), or as strings, or as arrays, or as other data types all come with a lot of non-obvious consequences and edge cases to deal with. I always use a provided "date" datatype from a library, and never try to roll my own with base data types if I have any choice in the matter. And they are still hard, depending on what range of dates you need to be able to handle.
You know, when I started working with computers (many moons ago) and found out about the 2038 problem, I didn't worry about it. After all, that will never affect me, right?
Well, it's 2022 and 2038 doesn't look that far away now. Hopefully I'll be retired by then and won't have to deal with it. But, something tells me that's not going to happen.
I talked to someone who worked in this team. A mere 30 min conversation opened my eyes to the complexity and he wasn’t even scratching the surface. It’s hard for most people to appreciate the true complexity here. I agree that accountability is needed but even a trillion dollars won’t be enough for bug free code - especially with dates.
The nature of this specific bug isn't something related to hard date stuff, like leap years, leap seconds, DST, or time zones. It's just that they formatted version strings as YYMMDDHHMM (e.g. 2201010001) and tried converting that number to an int32, causing an overflow once 2022 struck.
It's not even really important that it's a date bug from a testing perspective; it's just a bug and a signal of an insufficient testing pipeline. You make a product (including a definition file), you test it before publishing it. You have canaries. If testing it happens to involve moving the date forward, you do that.
How hard is it to write a test that checks every date in the next 5 years to make sure we know the function will not break without giving us sufficient time to publish a fix in the regular version pipeline?
Good point. It feels like what you're describing is like time travel to erase the bug from the timeline completely, vs. getting a one-time advanced warning. I guess for date-related bugs where you have no other way to avoid them, you would need to set the clocks forward at least as far as you have the capacity to get a fix in, regression tested, and get your users enough time to do the same.
We know how it was caused, bottom of reddit post is the update. The developers got clever and used a common method to store a version as an integer, but they never checked that they had enough space to store such a large number for the uncommon format they chose.
Being an amateur developper, I never tried to touch a date in another way than though a specialized module (arrow in Python, moment or luxon in JS, ...).
I know only a few such modules so everything that remotely looks as time/date computation is a nail for my universal hammer.
I learned this one the hard way when using jQuery Datatables, dates aren't natively supported for sorting, so had to integrate moment.js and learn the quirks of date formatting between it, Datatables, .net and sql, especially since with moment you uppercase everything MM/DD/YYYY vs MM/dd/yyyy, plus notation for AM/PM and seconds is also different.
I feel like after Y2K, we should've learned to never store two digit years again. If the format they used was actually YYYYMMDDhhmm, then it would've crashed as soon as someone tried to convert it to an int and they would've fixed it without another thought. Sure dates are hard, but a few simple rules cover a lot of problems.
Yeah, they converted the DateTime object into a string of the format YYMMddhhmm which for 2022 starts with 2201010000. Then they convert that into a signed long integer or 2,201,010,000
A long integer is 32 bits. Since it's signed, one of those bits are used for the sign and 31 are used to represent the actual number. With 31 bits, you can express numbers from 0 - 2^31 or 2,147,483,648. 2,201,010,000 is larger than 2,147,483,648.
If they used the format YYYYMMddhhmm, then their numbers for every year would have overflowed the field. Because 201,801,010,000, for example, is too bit to fit in the long. Every year past year 99 would be too big.
But, if it's, say 2008 and you realize that putting the thousand and hundreds will always make it overflow, 801,010,000 would not make it overflow. So why not just cut off thousands and hundreds? Because it's not like we'll run into a 1999/2000 problem before the software is replaced.
So this system was implemented sometime after 1999, and presumably after 2010, since leading zeros are truncated (ignored) in ints... which means this bug was implemented, pushed out, and no one for up to 12 years thought this could possibly be a problem, at microsoft?
They probably figure it will be no problem, who will still be using Exchange in 2100? Same thinking as the guys who set up all those databases in 1975. And at least once it overflows (again) it will be somebody else's problem to fix.
If you entered a birth date, the software would calculate the pet's age, and we noticed we had the odd quirk, like a 400 year-old cat etc. I couldn't see an obvious pattern to the anomaly, and it didn't occur often, so I created a support ticket.
After a couple of days, I received a response that 'dates were hard' and we should correct the ages manually as needed.
So there you have it: Dates are hard.
(No, the bug wasn't ever fixed.)