From: noemail@basdxcqvbe.com   
      
   On Sat, 19 Jun 2021 21:06:16 -0700 (PDT)   
   "muta...@gmail.com"  wrote:   
      
   > On Sunday, June 20, 2021 at 1:57:01 PM UTC+10, Rod Pemberton wrote:   
      
   > > > I'm thinking of replacing the Year 2038 problem   
   > > > with a Year 2030/2040/2050/etc recurring problem.   
   > > >   
   > > Did you drop the eight (8) from 2038 (thirty-eight)   
   > > for a zero (0) in 2030/2040/2050 above? Was that   
   > > an intentional change or just a mistake? I.e., are   
   > > you changing the issue from 2038 (thirty-eight)   
   > > to 2030 (thirty) and also shifting the Epoch from   
   > > 1970 to 1980? Or, are you just shifting the Epoch?   
   >   
   > I'm (proposing) doing both, automatically, starting in   
   > 2030, with an adjustment every 10 years after that,   
   > for eternity.   
   >   
   > [...]   
   >   
   > I was just planning on dynamically shifting that 1970.   
   >   
      
   It'd work on the software side, but you'd have the   
   side effect of dates and times being off every decade.   
   Why wouldn't you use a larger period like the nearly   
   seventy years from 1970 to 2038?   
      
   I don't remember enough about the CMOS RTC to know   
   if it's an issue.   
      
      
   --   
   What is hidden in the ground, when found, is hidden there again?   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)