bug#19302: 24.4.51; `date-to-time' fails after 2038

[Stefan Kangas <stefan@marxist.se>]

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