Subj : Re: 'Leap Second' to Be Added on New Year's Eve This Year
To : All
From :
[email protected]
Date : Sat Dec 31 2016 02:34 pm
Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year
From: Mark Lloyd <
[email protected]>
On 12/30/2016 07:48 PM, Keith Thompson wrote:
> Mark Lloyd <
[email protected]> 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)
