Conversation

Notices

1. LinuxWalt (@lnxw48a1) {3EB165E0-5BB1-45D2-9E7D-93B31821F864} (lnxw48a1@nu.federati.net)'s status on Sunday, 02-Jan-2022 11:38:32 UTC LinuxWalt (@lnxw48a1) {3EB165E0-5BB1-45D2-9E7D-93B31821F864}

   • GeniusMusing
   @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).
   • LinuxWalt (@lnxw48a1) {3EB165E0-5BB1-45D2-9E7D-93B31821F864} (lnxw48a1@nu.federati.net)'s status on Sunday, 02-Jan-2022 00:33:34 UTC LinuxWalt (@lnxw48a1) {3EB165E0-5BB1-45D2-9E7D-93B31821F864}

     • GeniusMusing
     @geniusmusing When I first read this, I thought it was FIPS. https://en.wikipedia.org/wiki/Federal_Information_Processing_Standards
   • Bob Jonkman (bobjonkman@gs.jonkman.ca)'s status on Monday, 03-Jan-2022 04:11:09 UTC Bob Jonkman

     in reply to
     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.
     LinuxWalt (@lnxw48a1) {3EB165E0-5BB1-45D2-9E7D-93B31821F864} likes this.
     LinuxWalt (@lnxw48a1) {3EB165E0-5BB1-45D2-9E7D-93B31821F864} repeated this.
   • LinuxWalt (@lnxw48a1) {3EB165E0-5BB1-45D2-9E7D-93B31821F864} (lnxw48a1@nu.federati.net)'s status on Monday, 03-Jan-2022 13:05:14 UTC LinuxWalt (@lnxw48a1) {3EB165E0-5BB1-45D2-9E7D-93B31821F864}

     in reply to
     Make that Y2K38.
   • LinuxWalt (@lnxw48a1) {3EB165E0-5BB1-45D2-9E7D-93B31821F864} (lnxw48a1@nu.federati.net)'s status on Tuesday, 04-Jan-2022 02:20:42 UTC LinuxWalt (@lnxw48a1) {3EB165E0-5BB1-45D2-9E7D-93B31821F864}

     • GeniusMusing
     • Bob Jonkman
     @geniusmusing @bobjonkman
     
     #Microsoft has patched the Y2K-alike bug in #Exchange. https://www.theregister.com/2022/01/03/exchange_servery2k22_flaw/
   • Alexandre Oliva (lxo@gnusocial.net)'s status on Tuesday, 04-Jan-2022 07:34:39 UTC Alexandre Oliva

     in reply to

     • Bob Jonkman
     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?
     Bob Jonkman likes this.
     Bob Jonkman and LinuxWalt (@lnxw48a1) {3EB165E0-5BB1-45D2-9E7D-93B31821F864} repeated this.
   • Bob Jonkman (bobjonkman@gs.jonkman.ca)'s status on Tuesday, 04-Jan-2022 10:07:25 UTC Bob Jonkman

     in reply to

     • Alexandre Oliva
     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
     LinuxWalt (@lnxw48a1) {3EB165E0-5BB1-45D2-9E7D-93B31821F864} repeated this.