7 ms·

Summary of the bug: Exchange tried to store "2201010001" (i.e. date time '22-01-01 00:00) in a 32-bit signed int, but INT_MAX is 2147483647 so the result is a n

Summary of the bug: Exchange tried to store "2201010001" (i.e. date time '22-01-01 00:00) in a 32-bit signed int, but INT_MAX is 2147483647 so the result is a negative number.

sdoering 5y ago
Damn. This reminds me of the alleged 'Nuclear Gandhi' [1]. Or the Swiss railway axle counter [2]. [1]: https://en.wikipedia.org/wiki/Nuclear_Gandhi https://en.wikipedia.org/wiki/Nuclear_Gandhi [2]: https://www.reddit.com/r/programming/comments/4sco75/the_axle_count_of_trains_in_switzerland_must_not/ https://www.reddit.com/r/programming/comments/4sco75/the_axl...
- alephxyz 5y ago
  That reddit post is a link to a Twitter post containing a link to an imgur image containing the relevant text
  - PostThisTooFast 5y ago
  - manachar 5y ago
    The future is weird.
29athrowaway 5y ago
Or std::numeric_limits<int>::max()
phkahler 5y ago
Oh they should have used an UNSIGNED number. /sarcasm
- jlv2 5y ago
  I'm sure that was the patch.
  - shakna 5y ago
    The current patch actually just changed the number of days allowed in December, to give the team time to patch it properly. The date reported is December 33rd, 2021.
    - jve 5y ago
      Source? Another tale to tell your grandkids when they ask about those weird dates...?
      - shakna 5y ago
        > The version of the updated scan engine starts with 2112330001; is this right? Should we be concerned that it seems to reference a date that does not exist? > The newly updated scanning engine is fully supported by Microsoft. While we need to work on this sequence longer term, the scanning engine version was not rolled back, rather it was rolled forward into this new sequence. The scanning engine will continue to receive updates in this new sequence.[0] [0] https://techcommunity.microsoft.com/t5/exchange-team-blog/email-stuck-in-exchange-on-premises-transport-queues/ba-p/3049447 https://techcommunity.microsoft.com/t5/exchange-team-blog/em...
hn_throwaway_99 5y ago
Storing dates in YYMMDDHHMM format but then saving that as an int seems like such an ... odd choice. Curious to how/why that decision was made, or if it was perhaps unintentional but nobody noticed before (e.g. comparison was done on those date values but nobody realized that they were for some reason coerced to ints, and nobody noticed because it still worked as expected).
- femto113 5y ago
  I can think of lots of reasons why it was made: sorting ints is fast, storing them is compact, etc. Doesn't mean it wasn't a terrible decision (with readily foreseeable consequences) but I don't find it irrational or even surprising.
  - hn_throwaway_99 5y ago
    > I can think of lots of reasons why it was made: sorting ints is fast, storing them is compact, etc. Of course, but in that case you would just store it as a normal date/timestamp value, e.g. ms or sec or heck even days since the epoch, truncated to days. Formatting it as a format string and then converting to an int is the part that's so weird.
    - zarzavat 5y ago
      You need to store two separate values for a zoneless datetime. Days since epoch and minutes/seconds since midnight. You can't do it with one integer without mixing it somehow.
  - hamburglar 5y ago
    I’d call this an irrational optimization in modern times for this particular problem space. I have no idea how long this scheme has been in use, but they’re basically ids for malware data releases, so even if you accumulated all the timestamps that have ever been used as these ids, it’s probably a few thousand, max, and growing at a predictable and pretty linear rate. Using clever encodings to save space or sort time in the context of an exchange server for this amount of data probably hasn’t been an appropriate choice in at least a couple decades.
grishka 5y ago
Why is anyone using two-digit years anywhere at all? This approach has already caused a lot of trouble 22 years ago. Do people learn nothing from their past mistakes?
- btgeekboy 5y ago
  Because these files aren't going backward in time, and it's quite unlikely this code will be in use in 78 years.
  - rapind 5y ago
    Unless you're importing historical records...
    - bee_rider 5y ago
      It seems likely that this is an issue with the code specifically, rather than the encoding of the files, based on the fact that they managed to roll out a fix pretty quickly.
      - rapind 5y ago
        I agree, but parent was responding to a more general comment of "Why is anyone using two-digit years anywhere at all?".
  - cm2187 5y ago
    Well clearly they didn’t even seem to expect this code to be in use in 2022!
  - smnrchrds 5y ago
    > it's quite unlikely this code will be in use in 78 years Famous last words.
    - perl4ever 5y ago
      I know of a system that uses "1/1/2099" everywhere an "infinity" date is needed. The problem with fixing it, is nobody thinks it will be their problem.
baskethead 5y ago
This is really sloppy code. This should have been caught in a code review very easily. Maybe this code is dozens of years old and no one thought it would be in production but there should have been a test case for this at the very least. Meanwhile I was denied a job at Microsoft out of college almost 30 years ago because I didn’t remember how to divide coins properly to find the fake coin.
runeks 5y ago
> […] so the result is a negative number. No, the result is a parser failure. That’s what the error message[1] says, at least. [1] https://news.ycombinator.com/item?id=29775547 https://news.ycombinator.com/item?id=29775547

Summary of the bug: Exchange tried to store "2201010001" (i.e. date time '22-01-01 00:00) in a 32-bit signed int, but INT_MAX is 2147483647 so the result is a negative number.

sdoering 5y ago

Damn. This reminds me of the alleged 'Nuclear Gandhi' [1]. Or the Swiss railway axle counter [2]. [1]: https://en.wikipedia.org/wiki/Nuclear_Gandhi https://en.wikipedia.org/wiki/Nuclear_Gandhi [2]: https://www.reddit.com/r/programming/comments/4sco75/the_axle_count_of_trains_in_switzerland_must_not/ https://www.reddit.com/r/programming/comments/4sco75/the_axl...

alephxyz 5y ago
That reddit post is a link to a Twitter post containing a link to an imgur image containing the relevant text
- PostThisTooFast 5y ago
- manachar 5y ago
  The future is weird.

29athrowaway 5y ago

Or std::numeric_limits<int>::max()

phkahler 5y ago

Oh they should have used an UNSIGNED number. /sarcasm

jlv2 5y ago
I'm sure that was the patch.
- shakna 5y ago
  The current patch actually just changed the number of days allowed in December, to give the team time to patch it properly. The date reported is December 33rd, 2021.
  - jve 5y ago
    Source? Another tale to tell your grandkids when they ask about those weird dates...?
    - shakna 5y ago
      > The version of the updated scan engine starts with 2112330001; is this right? Should we be concerned that it seems to reference a date that does not exist? > The newly updated scanning engine is fully supported by Microsoft. While we need to work on this sequence longer term, the scanning engine version was not rolled back, rather it was rolled forward into this new sequence. The scanning engine will continue to receive updates in this new sequence.[0] [0] https://techcommunity.microsoft.com/t5/exchange-team-blog/email-stuck-in-exchange-on-premises-transport-queues/ba-p/3049447 https://techcommunity.microsoft.com/t5/exchange-team-blog/em...

hn_throwaway_99 5y ago

Storing dates in YYMMDDHHMM format but then saving that as an int seems like such an ... odd choice. Curious to how/why that decision was made, or if it was perhaps unintentional but nobody noticed before (e.g. comparison was done on those date values but nobody realized that they were for some reason coerced to ints, and nobody noticed because it still worked as expected).

femto113 5y ago
I can think of lots of reasons why it was made: sorting ints is fast, storing them is compact, etc. Doesn't mean it wasn't a terrible decision (with readily foreseeable consequences) but I don't find it irrational or even surprising.
- hn_throwaway_99 5y ago
  > I can think of lots of reasons why it was made: sorting ints is fast, storing them is compact, etc. Of course, but in that case you would just store it as a normal date/timestamp value, e.g. ms or sec or heck even days since the epoch, truncated to days. Formatting it as a format string and then converting to an int is the part that's so weird.
  - zarzavat 5y ago
    You need to store two separate values for a zoneless datetime. Days since epoch and minutes/seconds since midnight. You can't do it with one integer without mixing it somehow.
- hamburglar 5y ago
  I’d call this an irrational optimization in modern times for this particular problem space. I have no idea how long this scheme has been in use, but they’re basically ids for malware data releases, so even if you accumulated all the timestamps that have ever been used as these ids, it’s probably a few thousand, max, and growing at a predictable and pretty linear rate. Using clever encodings to save space or sort time in the context of an exchange server for this amount of data probably hasn’t been an appropriate choice in at least a couple decades.

grishka 5y ago

Why is anyone using two-digit years anywhere at all? This approach has already caused a lot of trouble 22 years ago. Do people learn nothing from their past mistakes?

btgeekboy 5y ago
Because these files aren't going backward in time, and it's quite unlikely this code will be in use in 78 years.
- rapind 5y ago
  Unless you're importing historical records...
  - bee_rider 5y ago
    It seems likely that this is an issue with the code specifically, rather than the encoding of the files, based on the fact that they managed to roll out a fix pretty quickly.
    - rapind 5y ago
      I agree, but parent was responding to a more general comment of "Why is anyone using two-digit years anywhere at all?".
- cm2187 5y ago
  Well clearly they didn’t even seem to expect this code to be in use in 2022!
- smnrchrds 5y ago
  > it's quite unlikely this code will be in use in 78 years Famous last words.
  - perl4ever 5y ago
    I know of a system that uses "1/1/2099" everywhere an "infinity" date is needed. The problem with fixing it, is nobody thinks it will be their problem.

baskethead 5y ago

This is really sloppy code. This should have been caught in a code review very easily. Maybe this code is dozens of years old and no one thought it would be in production but there should have been a test case for this at the very least. Meanwhile I was denied a job at Microsoft out of college almost 30 years ago because I didn’t remember how to divide coins properly to find the fake coin.

runeks 5y ago

> […] so the result is a negative number. No, the result is a parser failure. That’s what the error message[1] says, at least. [1] https://news.ycombinator.com/item?id=29775547 https://news.ycombinator.com/item?id=29775547