Subj : Re: 'Leap Second' to Be Added on New Year's Eve This Year To : All From : Ww84wa@aim.com Date : Sun Jan 01 2017 09:31 pm 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) .