[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19302: 24.4.51; `date-to-time' fails after 2038
From: |
Stefan Kangas |
Subject: |
bug#19302: 24.4.51; `date-to-time' fails after 2038 |
Date: |
Sun, 01 Mar 2020 02:30:54 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>>> I agree, but not by making Emacs do heroic hacks, instead we can make
>>>>> the problem go away by telling the user to update his C library.
>>>> What C library version fixes this?
>>> I don't know. But as long as the problem is not sufficiently important
>>> to fix it in the C library, I don't see why we should fix it in Emacs.
>> I agree. Does anyone object to closing this as wontfix?
>
> Side note: IIUC glibc now has something working and distributions like
> Debian are now trying to figure out how to go about incorporating it
> (since it expands time_t to 64bit on 32bit systems, forcing an
> ABI-incompatible change which can create more ABI-incompatible changes
> in libraries that include a time_t in their API).
Interesting. I found the following article regarding Debian:
https://lwn.net/Articles/812767/
If I understand correctly, we will have to make some accomodations
once this is fully merged, according to the current proposal.[1] The
glibc page, last edited 2018-09-19, says:
e.g. the 64-bit implementation of clock_gettime would be named
clock_gettime64.
That seems to also be the content of a series of proposed patches
currently being discussed on the glibc mailing list.[2]
In summary, we might want to keep this bug report open until we have
implemented support for the new types.
Best regards,
Stefan Kangas
Footnotes:
[1] https://sourceware.org/glibc/wiki/Y2038ProofnessDesign
[2] See for example:
https://sourceware.org/ml/libc-alpha/2020-02/msg00873.html