From: Wally W.    
   Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year   
       
   On Sun, 01 Jan 2017 19:44:48 -0500, Wally W. wrote:   
       
   >On Sun, 1 Jan 2017 16:12:27 -0600, Mark Lloyd wrote:   
   >   
   >>On 01/01/2017 12:46 PM, Wally W. wrote:   
   >>   
   >>[snip]   
   >>   
   >>> As I understand it, NT time uses a signed integer and tops out at   
   >>> 0x7FFFFFFFFFFFFFFF = in the year 30828   
   >>>   
   >>> Unhappily, no sources suggest using negative integers will allow   
   >>> setting the timestamp before the year 1600.   
   >>   
   >>What is the resolution of this clock? You get hundreds of billions of    
   >>years if you count seconds since 1970.   
   >   
   >For Windows NT, GetSystemTimeAsFileTime is in 100s of nanonsconds   
   >(tenths of microseconds) since 1/1/1600.   
   >   
   >Doing the math:   
   >   
   >0x7FFFFFFFFFFFFFFF = 9223372036854775807   
   >   
   >So:   
   >   
   >9223372036854775807 / 365.25 / 86400 / (1e7)   
   > =  29,227   
   >   
   >29,227 + 1600 =  30,827   
   >   
   >That is close to 30,828.   
   >   
   >My approximation for leap years is too crude for a span of 30,000+   
   >years.   
   >   
   >Unix tops out much later in the table at the link above.   
       
   Above??!   
       
   I meant this one:   
   https://en.wikipedia.org/wiki/System_time   
       
   I forgot to paste it before.   
       
       
   >If I want to use the same (really durable) hardware to retrieve my   
   >backups in the year 292,000,000 AD, I should start using Linux now.   
   >   
   >Actually, I would have liked to have started using Linux exclusively   
   >years ago.    
   >   
   >   
   >>1600 is a leap year, like 2000 and 2400. Maybe it has something to do    
   >>with that.   
   >>   
   >>> Otherwise, timestamps could be set for any date in known history; as   
   >>> in 4004 BC, which by some counts includes Day One.   
   >>   
   >>The PHP I use has a strange "hole", where you can't set (with mktime) a    
   >>year in the range of 0-100*. IIRC earlier years can be set, but it's one    
   >>off (it thinks there is a year 0). 4004 BC** would be specified as -4003.   
   >>   
   >>* - I think this is a "convenience" that made sense with a 32-bit time_t    
   >>where it adds 2000 to 0-79 and 1900 to 80-100, both 0 and 100 become 2000.   
   >>   
   >>** - I try to use CE / BCE instead of AD / BC. The numbers are the same,    
   >>and it avoids a particular assumption.   
   >>   
   >>[snip]   
       
      
   --- ViaMAIL!/WC v2.00   
    * Origin: ViaMAIL! - Lightning Fast Mailer for Wildcat!  (1:261/20)