6 ms·

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 thei

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. So there you have it: Dates are hard. (No, the bug wasn't ever fixed.)

goda90 5y ago
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.
- OisinMoran 5y ago
  Do you mean it would crash from that number being too big for a byte-sized int? Just checking I'm not missing anything here.
  - bena 5y ago
    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.
    - genewitch 5y ago
      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?
- mark-r 5y ago
  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.
BrandoElFollito 5y ago
> So there you have it: Dates are hard. 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.
- joenathanone 5y ago
  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. Dates are hard.
  - BrandoElFollito 5y ago
    > date formatting between it Oh yes. The nightmare of software that reinvent the wheel. Instead of using ISO 8601 [1] they feel the need to do something else. I currently suffer with how time was botched in the otherwise great backup program Borg [2] [1] https://xkcd.com/1179/ https://xkcd.com/1179/ - yes, xkcd has an entry for everything [2] https://www.borgbackup.org/ https://www.borgbackup.org/
    - kiwijamo 5y ago
      As a Borg user, could you explain more about the issues with date formatting in Borg?
      - BrandoElFollito 5y ago
        The timestamps are naive (no timezone) and therefore hardly useable for a non-local installation (backups on/to servers in different locations). See for instance https://github.com/borgbackup/borg/issues/4832 https://github.com/borgbackup/borg/issues/4832
OisinMoran 5y ago
It's painful to learn of such a bug and have no insight into how it was caused. Would love to get my hands on the codebase to figure this one out! In another universe The 400 Year Old Cat could have been our 500 Mile Email.
- petee 5y ago
  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. Its just another form of y2k, or y2038.
  - NobodyNada 5y ago
    The comment you replied to is talking about the 400-year-old-cat from the previous comment, not the Exchange bug from the article.
    - petee 5y ago
      Oops! Thank you, I lost track of the thread while scrolling back up! Please disregard, as I'd love to know what that bug is too
kingcharles 5y ago
Did you check with the cat to see if it was actually 400 years old?
- Swenrekcah 5y ago
  You joke, but if they had been tracking shark ages instead it might well have been! https://www.bbc.com/news/science-environment-37047168 https://www.bbc.com/news/science-environment-37047168
throwawayboise 5y ago
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.
- SamuelAdams 5y ago
  Semi-related, one of my favorite posts on UTC. Seems simple to use until it’s not. https://zachholman.com/talk/utc-is-enough-for-everyone-right https://zachholman.com/talk/utc-is-enough-for-everyone-right
- bfung 5y ago
  Heh, if dates are hard now, just wait till 2038 (https://en.m.wikipedia.org/wiki/Year_2038_problem https://en.m.wikipedia.org/wiki/Year_2038_problem)
  - Corrado 5y ago
    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.
    - pjmlp 5y ago
      The issue is that even when retired, it might hit us in one form or the other.
- JdeBP 5y ago
  The knowledge has indeed existed for years. * https://news.ycombinator.com/item?id=4128208 https://news.ycombinator.com/item?id=4128208
lopatin 5y ago
Sure, dates are hard. But I think it's too generous to say Microsoft shouldn't be blamed for releasing such a bug.
- rbanffy 5y ago
  Dates are hard but Microsoft is a trillion dollar company that sells products on every locale and timezone on the planet. Something like this is unacceptable.
  - aldebran 5y ago
    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.
    - lopatin 5y ago
      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. Date bugs are hard, but this one isn't.
      - deleted 5y ago
        [deleted]
      - jrootabega 5y ago
        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.

goda90 5y ago

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.

OisinMoran 5y ago
Do you mean it would crash from that number being too big for a byte-sized int? Just checking I'm not missing anything here.
- bena 5y ago
  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.
  - genewitch 5y ago
    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?
mark-r 5y ago
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.

BrandoElFollito 5y ago

> So there you have it: Dates are hard. 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.

joenathanone 5y ago
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. Dates are hard.
- BrandoElFollito 5y ago
  > date formatting between it Oh yes. The nightmare of software that reinvent the wheel. Instead of using ISO 8601 [1] they feel the need to do something else. I currently suffer with how time was botched in the otherwise great backup program Borg [2] [1] https://xkcd.com/1179/ https://xkcd.com/1179/ - yes, xkcd has an entry for everything [2] https://www.borgbackup.org/ https://www.borgbackup.org/
  - kiwijamo 5y ago
    As a Borg user, could you explain more about the issues with date formatting in Borg?
    - BrandoElFollito 5y ago
      The timestamps are naive (no timezone) and therefore hardly useable for a non-local installation (backups on/to servers in different locations). See for instance https://github.com/borgbackup/borg/issues/4832 https://github.com/borgbackup/borg/issues/4832

OisinMoran 5y ago

It's painful to learn of such a bug and have no insight into how it was caused. Would love to get my hands on the codebase to figure this one out! In another universe The 400 Year Old Cat could have been our 500 Mile Email.

petee 5y ago
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. Its just another form of y2k, or y2038.
- NobodyNada 5y ago
  The comment you replied to is talking about the 400-year-old-cat from the previous comment, not the Exchange bug from the article.
  - petee 5y ago
    Oops! Thank you, I lost track of the thread while scrolling back up! Please disregard, as I'd love to know what that bug is too

kingcharles 5y ago

Did you check with the cat to see if it was actually 400 years old?

Swenrekcah 5y ago
You joke, but if they had been tracking shark ages instead it might well have been! https://www.bbc.com/news/science-environment-37047168 https://www.bbc.com/news/science-environment-37047168

throwawayboise 5y ago

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.

SamuelAdams 5y ago
Semi-related, one of my favorite posts on UTC. Seems simple to use until it’s not. https://zachholman.com/talk/utc-is-enough-for-everyone-right https://zachholman.com/talk/utc-is-enough-for-everyone-right
bfung 5y ago
Heh, if dates are hard now, just wait till 2038 (https://en.m.wikipedia.org/wiki/Year_2038_problem https://en.m.wikipedia.org/wiki/Year_2038_problem)
- Corrado 5y ago
  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.
  - pjmlp 5y ago
    The issue is that even when retired, it might hit us in one form or the other.
JdeBP 5y ago
The knowledge has indeed existed for years. * https://news.ycombinator.com/item?id=4128208 https://news.ycombinator.com/item?id=4128208

lopatin 5y ago

Sure, dates are hard. But I think it's too generous to say Microsoft shouldn't be blamed for releasing such a bug.

rbanffy 5y ago
Dates are hard but Microsoft is a trillion dollar company that sells products on every locale and timezone on the planet. Something like this is unacceptable.
- aldebran 5y ago
  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.
  - lopatin 5y ago
    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. Date bugs are hard, but this one isn't.
    - deleted 5y ago
      [deleted]
    - jrootabega 5y ago
      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.