back to article Microsoft patches Y2K-like bug that borked on-prem Exchange Server

Microsoft has kicked off 2022 by issuing a patch for Exchange Server 2016 and 2019, which both possessed a “latent date issue” that saw emails queued up instead of being dispatched to inboxes. “The problem relates to a date check failure with the change of the new year,” states a January 1st post to the Exchange Blog. …

  1. John Brown (no body) Silver badge

    Seriously?

    This sounds like a result of some legacy code, a good few years old which was expected to be replaced and then was forgotten about. Maybe the coder who marked it in his/her calendar or ToDo list left and no one else knew about it.

    As mentioned in the articles, it's very Y2K-like, no one expected the code to still be in use after it's "Use By" date.

    1. Gene Cash Silver badge

      Re: Seriously?

      This isn't "legacy" - it's a horrible hack, as they're trying to encode a character based representation into a numeric variable and seems to be the result of some horrible mental confusion. This should have never been written in the first place. They need an absolute thrashing.

      I would not call them a "coder" any more than someone that "programs HTML"

      1. Anonymous Coward
        Facepalm

        Re: Seriously?

        > [ ... ] they're trying to encode a character based representation into a numeric variable [ ... ]

        That's not what's going on here.

        It's pure stupidity on the part of the implementor - namely Microsoft.

        They decided to use a signed 32-bit integer instead of an unsigned 64-bit integer to represent a date - namely the type time_t.

        Maximum possible value of a 32-bit signed integer: 2,147,483,647. Evidently, 2,201,010,001 won't fit, so it overflows.

        Maximum possible value of a 64-bit unsigned integer: 18,446,744,073,709,551,615.

        If they changed signed to unsigned but kept the 32-bit integer size in their patch - which is very likely, given Microsoft's legendary QOI - they're going to run into the time_t problem in 2038.

        They only had 22 years to think about this, so we gotta cut them some slack.

        Congrats to Microsoft for making everyone re-live the party atmosphere of 12/31/1999. Cue mandatory Prince song here.

        1. Flocke Kroes Silver badge

          Re: Seriously?

          The current fix: Represent 2022-01-02 as 2021-12-33. Using the same logic they are good until 2024-12-19 12:47. If they switch to uint32_t they get to 2042-12-31 23:59 without trickery and 2042-94-96 72:95 works out as 2050-01-07 01:35. I could live to see this bug back again at the start of 2043 but 2050 is probably past my sell by date <sarcasm>so there is no need to switch to a 64-bit type ever</sarcasm>!

          1. steve11235

            Re: Seriously?

            Sign, sign

            Everywhere a sign

            Blockin' out the scenery

            Breakin' my mind

            Do this, don't do that

            Can't you read the sign?

            If you don't recognize this, then you're too young.

            1. Chris G Silver badge

              Re: Seriously?

              I'm definitely not too young but I was learning to play African drums in '71 in Haverstock Hill, I had to google the lyrics.

        2. Paul Crawford Silver badge

          Re: Seriously?

          It is more than pure stupidity as this is not a time_t limit, its signed roll-over is still 2038 so a bit more to go as today is only 1641290719

          Nope, what they appear to have done is use an integer as a 'string' YYMMDDhhmm for some WTF reason. Honestly that is so much worse as clearly they have not bothered to use any standard (and hopefully tested) time library, not POSIX time_t nor even win32 calls, in order to handle things but rolled their own incompetent hack.

        3. sbooth

          Re: Seriously?

          No the known 2038 bug is when storing dates as seconds from the epoch and applies to signed 32-bit https://en.wikipedia.org/wiki/Year_2038_problem

          Microsoft have hit the limit early because they are using a less efficient encoding

          they take the 6 2-digit YY MM dd HH mm SS fields and encode these as base 100 numbert then convert to binary as the valid ranges in all but the year fields have maximum values less than 99 there are huge unused ranges and they ran out of space now.

      2. J. Cook Silver badge

        Re: Seriously?

        Yeah. string to signed 32? what. the. actual. feck. there's something like 35242 different ways to take a time/date string and represent it as a number (My personal favorite is unix epoch), and yet they had to make another one.

    2. Anonymous Coward
      Anonymous Coward

      Re: Seriously?

      This was not just Microsoft. SonicWALL's on-prem email security appliances GUI stopped updating at New Years also - https://www.sonicwall.com/support/knowledge-base/email-security-stops-logging-junkbox-and-message-logs/220103080034540/

      So far SonicWALL has not explained this. Email did continue to flow through the devices.

  2. Gene Cash Silver badge

    "the fix can be tricky to apply, and sometimes fails"

    So not much different that most other Microsoft or Oracle patches, then.

  3. ShadowSystems Silver badge
    Joke

    There's still time...

    Since the suffix "K" in computers refers to the value 1024, "2K" would thus be 2048. Any "Y2K" issues are still 26 years in the future, right?

    *Runs away before someone clubs me silly with a ClueBy4*

    1. Huw L-D

      Re: There's still time...

      http://ars.userfriendly.org/cartoons/?id=20211231

  4. Mister Dubious
    Boffin

    Another date bug?

    (Yawn.) Wake me in 2038.

  5. ssieler

    There are two things to observe here (in naming updates with yymmdd####)...

    1. changing the type from the equivalent of "int32_t" to "uint32_t" would solve the problem for several thousand years.

    2. Does everyone understand that by reserving four digits for an update counter *within a day*, Microsoft effectively said "our software is sooooo bad, we might actually have to post a thousand or more updates *in a single day*"? Sheesh! :)

    1. Doctor Syntax Silver badge

      1. changing the type from the equivalent of "int32_t" to "uint32_t" would solve the problem for several thousand years.

      But they'd have lost the ability to handle BC dates.

      2. Does everyone understand that by reserving four digits for an update counter *within a day*, Microsoft effectively said "our software is sooooo bad, we might actually have to post a thousand or more updates *in a single day*"?

      It's the sort of conservative approach they should have taken in handling the date in the scanner.

  6. david 12 Silver badge

    It's been a problem for 20 years already

    Post-dated spam has been coming in for at least the last 20 years. It didn't cause failure of delivery in the version of Exchange I was using -- but it did cause failure of aging and deletion, with post '22 mail never matching the deletion criteria.

  7. Twanky Silver badge
    Trollface

    Bad people

    The real problem is you bad people who insist on running your own mail servers.

    We've had the correct fix available for years but you refuse to comply. You. Will. Subscribe.

    Microsoft.

    1. J. Cook Silver badge

      Re: Bad people

      Indeed; I think they are trying the 'make the admin's life such a living hell that migrating to office248 is easier on the sanity' play.

  8. RSW

    Does this show that MS don't eat there own dog food on the back end, as web based outlook didn't stop working?

  9. This post has been deleted by its author

  10. Pascal Monett Silver badge
    Flame

    It's 2022 and we're still coding dates as numbers (badly) or strings (worse)

    Object-Oriented coding exists since when already ? Why are we still coding dates in strings instead of having a date object that has, say, four elements : year, month, day, timezone ? We should have a time object with hour, minutes, seconds, hundredths. And we could have a date-time object inheriting from both.

    That would avoid all these shenanigans about trying to convert dates into numbers.

    And, Borkzilla, you might want to check your Excel code. It works there.

    1. thondwe

      Re: It's 2022 and we're still coding dates as numbers (badly) or strings (worse)

      OOPS started with Simula-67? So in 2021/2 they are bodging strings of numbers to integers because they can even be bothered to write a line of code to convert to seconds...

    2. yetanotheraoc Silver badge

      Re: It's 2022 and we're still coding dates as numbers (badly) or strings (worse)

      "That would avoid all these shenanigans about trying to convert dates into numbers."

      Everything in a computer is a sequence of 1s and 0s. Even your precious Objects are just a collection of numbers. Conversion will always be necessary, if not by you then by the library you call. "yyddmmssff" -.> int32 is an egregiously bad way to do it, but the solution is "library", not "objects".

  11. Dave Pickles

    VMS once had a similar problem

    Sometime around 2001 there was a similar problem with VAX/VMS. A library function for date handling was using the ASCII representation of the UNIX system time, and broke when the count of seconds since 1-Jan-1970 passed 1,000,000,000.

    1. yetanotheraoc Silver badge

      Re: VMS once had a similar problem

      This problem is as old as time.

  12. Blackjack Silver badge

    First they came for the Printer

    Then they came for the e-mail

    What's next, the hardware? Ah right Windows 11 already does that.

  13. Howard Sway Silver badge

    2022, the year of the ex-exchange server

    There must be stories out there of companies where this year someone said "I'm sick of paying our admins to be on standby every new year's eve in case there's a date rollover problem - it just never happens!".

    But for those of us who are unaffected, we can enjoy this nice example of "premature optimisation is the root of all evil".

  14. yetanotheraoc Silver badge

    Do the right thing

    On the bright side, Exchange just left the emails in a queue. On a mail server that must be the equivalent of "default error handler".

  15. Hairy Wolf
    FAIL

    Year 2100 bug

    I am surprised that no one has made more of the use of two digit year. That is a year 2100 bug in the waiting, so soon after Y2K. Still 78 years to go so plenty of time to let this fester.

    1. Hazmoid

      Re: Year 2100 bug

      And a fortune to be made certifying and selling new hardware and software that is guaranteed not to have this problem. Just look at what happened with Y2K.

  16. Trixr

    Smells like stealth deprecation of on-prem Exchange

    Honestly, it's hard not to hear the black helicopters overhead from this latest screw-up with MSFT's avowed intention of forcing everyone into the cloud. Although, since a hybrid Azure deployment still requires Exchange servers on prem even if all mailboxes are in EXO, it's hard to know if it's Exchange or simply on-prem AD they're really after. (I joke. Kind of.)

    That said, it's classic business as usual with Exchange CUs. While the window between OS patch releases and production deployment has increasingly narrowed in my little world, there's very little that'd induce me to apply an Exchange CU less than 2 months after release. In fact, in recent years, there have been perhaps two I've applied within a month. (Applied other workarounds for a few others in the interim. )

    For even the "super urgent" ones, I've waited at least 10 days after release and carefully reviewed the changes... and waited for the screaming to die down and the fixes to be released.

  17. IGotOut Silver badge

    Don't worry

    there still plenty for your <insert device> to fail at the next summer time change... And then in two years we have another leap year.

    Oh and the leap second is due in June....

    1. nowster

      Re: Don't worry

      No leap second this year: https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like