Microsoft’s Exchange Y2k+22 Bug


Microsoft working on fix for “Year 2022” bug where Microsoft Exchange emails might be stuck in transport queues

Anyone using Microsoft Exchange Server might be in for a surprise, in the form of empty inboxes or mails not being delivered.

They use a long to hold the date (E.g. 20220101000001), which is now too small to contain the numeric long form date. This affects the spam and virus checking system.

We are using a third party system, so I am waiting to see if and how we are affected, when I get to work tomorrow!

Happy New Year, from Microsoft!

Comments (5)

5 responses to “Microsoft’s Exchange Y2k+22 Bug”

  1. navarac

    Does no-one in Redmond look back at past problems and project forward? Just in case? Mind you a lot in Redmond were probably at school in 1999/2000 !!

  2. anoldamigauser

    "Those who cannot remember the past are condemned to repeat it."

    When they went to 64-bit in Windows, they left the definition of a long integer as a 32 bit, since they still sold 32-bit versions of Windows. One would think that at this point they would have gone through their own products and changed the variable definitions.

  3. anoldamigauser

    "We learn from history that we do not learn from history"

    George Hegel

  4. Paul Thurrott

    This is now fixed.

  5. hrlngrv

    MSFT has had problems with bad datatype choices in the past. Excel 97 through 2003 didn't support all-rows range references (except where an argument had to be a range reference) because they used unsigned 16-bit integers for the .Rows property, and that topped out at 2^16-1 rather than 2^16 (the number of rows in those versions).

    I guess MSFT 'best practices' MANDATE that the server developer team NEVER UNDER ANY CIRCUMSTANCES learn anything from the Office developer team, and probably vice versa.