From: Wally W. 
Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year
 
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.
 
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)