Subj : Re: 'Leap Second' to Be Added on New Year's Eve This Year To : All From : Not@mail.invalid Date : Sat Dec 31 2016 14:34:00 Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year From: Mark Lloyd On 12/30/2016 07:48 PM, Keith Thompson wrote: > Mark Lloyd writes: >> On 12/30/2016 04:37 PM, Keith Thompson wrote: >> >> [snip] >> >>> The time is stored in a time_t value returned by the time() >>> function. The time_t type is required to be a real type (integer >>> or floating-point, not complex) capable of representing times. >>> (On many systems it's a signed integer representing seconds since >>> 1970-01-01 00:00:00 UTC.) >> >> Used to be 32-bit, why I thought Y2K was going to be much less of a >> problem than Y2.038K (Jan 17 2038 IIRC). > [...] > > Tue 2038-01-19 03:14:08 UTC I knew it was around that time, from having to deal with that when my website was on a 32-bit server. IIRC the negative limit is in December 1901. > 64-bit systems already use a 64-bit signed integer for time_t, which > postpones the problem for about 292 billion years. And since C requires > long long to be at least 64 bits, I expect that 32-bit systems (and > smaller ones, if any) will transition to 64-bit time_t before 2038. 2^63 = 9.22337203685e+18 seconds, or 292,277,024,627 years (assuming leap year rules don't change). > Unlike 2-digit years, I suspect that most stored time_t values (which > are rarely displayed) are in files that can be converted reasonably > easily. > -- Mark Lloyd http://notstupid.us/ "Call on God, but row away from the rocks." [Indian proverb] --- ViaMAIL!/WC v2.00 * Origin: ViaMAIL! - Lightning Fast Mailer for Wildcat! (1:261/20) .