From: muta...@gmail.com   
      
   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.   
      
   > Of course, you can always search the C   
   > specifications for 1970 or 1980 perhaps in   
   > conjunction with January in you wish to   
   > determine the truth for yourself, as I've   
   > gotten tired of looking up stuff in the C   
   > specifications for other people, which they   
   > could've found themselves, and which usually   
   > confirms exactly what I stated.   
      
   I already know what the C standard says, and I've   
   already got a conforming implementation. I chose   
   to use 1970 the same as is normally done (but   
   not mandated by C90). You can see "1970" here:   
      
   https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/time.c   
      
   I was just planning on dynamically shifting that 1970.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)