1 |
On 2017-07-14, Jigme Datse Yli-RAsku <jigme.datse@×××××××××××××××.com> wrote: |
2 |
> |
3 |
> On 2017-07-14 08:15, Andrew Tselischev wrote: |
4 |
>> On Fri, Jul 14, 2017 at 08:42:01PM +0700, Vadim A. Misbakh-Soloviov wrote: |
5 |
>> >> when time_t reaches 2 billion. |
6 |
>> > |
7 |
>> > He meant 2k38 problem, when time_t will overflow int32 :) |
8 |
>> |
9 |
>> I would bet that somewhere there is a quick-job shell script that parses |
10 |
>> unix timestamps with regular expressions and assumes they start with a 1. :D |
11 |
>> |
12 |
|
13 |
> Why do I feel that we've already gone through at least one upgrade |
14 |
> of "Unix Time" already. I'm not sure if it was something like going |
15 |
> from int16 to int32, or more that it went from signed int32 to |
16 |
> unsigned int32. |
17 |
|
18 |
Well, the return type for time() changed from "int" (or was it long?) |
19 |
to "time_t" many years back. That said, the actual underlying |
20 |
representation has never changed on 32-bit Linux systems. Posix |
21 |
requires it to be signed, and on 32-bit Linux systems, it's still |
22 |
going to overflow in 2038 -- same as it ever was. |
23 |
|
24 |
NetBSD and OpenBSD both changed to signed-64 on both 32-bit and 64-bit |
25 |
archetectures. Maybe that's what you're thinking of? |
26 |
|
27 |
|
28 |
-- |
29 |
Grant Edwards grant.b.edwards Yow! Here I am in the |
30 |
at POSTERIOR OLFACTORY LOBULE |
31 |
gmail.com but I don't see CARL SAGAN |
32 |
anywhere!! |