Show Navigation
Conversation
Notices
-
@geniusmusing
> this is caused by Microsoft using a signed int32 variable to store the value of a date, which has a maximum value of 2,147,483,647
This is basically a Y2K / Y2K32 bug. We’ve known such things could happen since the late 1990s, so I’m really surprised that #Microsoft didn’t use a wider datatype (int64 at least).
-
@geniusmusing When I first read this, I thought it was FIPS. https://en.wikipedia.org/wiki/Federal_Information_Processing_Standards
-
From what I can tell, they were using the decimal digits of the 32-bit number as a sort of BCD, with the base10 digits representing portions of the date. The example used is "the new date value of 2,201,010,001 is over the max value of 'long' int32 being 2,147,483,647". So, YY MMDDHHMM ?
What an extraordinarily stupid way to represent a date.
-
Make that Y2K38.
-
@geniusmusing @bobjonkman
#Microsoft has patched the Y2K-alike bug in #Exchange. https://www.theregister.com/2022/01/03/exchange_servery2k22_flaw/
-
what's most incredible about this date representation is that it was introduced after Y2K. it wouldn't have worked up to [19]99
think about it. someone implemented that after all the many years of preparation and patching decades-old systems for Y2K, knowing (or, worse, without realizing) that it had at most a couple of decades of use. how screwy and irresponsible is that?
-
According The Register's forum, this is the patch: "The current fix: Represent 2022-01-02 as 2021-12-33."
https://forums.theregister.com/forum/all/2022/01/03/exchange_servery2k22_flaw/#c_4389861