From: nowhere@never.at   
      
   On 20.06.2021 07:26, Rod Pemberton wrote:   
      
   [...Year 2038 problem]   
   >>>> I was just planning on dynamically shifting that 1970.   
      
   I never had this problem because my file-system stores date and   
   time in a less restricted format:   
   YYYY,MM,DD,Hr,Min,Sec,Milli-Second [2021_06_18_11:30:59.999]   
   (4 + 5*2 + 3 BCD nibbles +4 bits for ownership flags)   
   9 bytes altogether, RTC talks BCD, easy readable in a hex-dump   
   and year 0000 to 9999 could be enough for a while :)   
      
   > 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.   
      
   In the old days there was only one CMOS byte used, written by   
   BIOS or the OS. Newer south-bridge stuff can do lap years and   
   daylight-saving and even lap seconds by itself.   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)