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

[Ivan Shmakov]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> From: Lars Magne Ingebrigtsen   Date: Tue, 09 Dec 2014 19:31:20 +0100
>>>>> Eli Zaretskii <eliz@gnu.org> writes:

 >>> So such an Emacs will be broken anyway after 2038, because it will
 >>> be unable to interpret file attributes,

        I see no way a platform which uses 32-bit time_t could possibly
        return file attributes pointing beyond 2038.

 >>> use interval timers, etc.

        Yes.  However, I’m could hardly imagine a use case for interval
        timers pointing to some quarter a century in the future.

 >> The problem is in parsing dates in the far future.  Web pages, for
 >> instance, popularly use an Expiry: header saying that the page
 >> expires in the year 2100 as a synonym for "never expires".

 > So we are going now to reinvent all the strftime stuff, complete with
 > localized names of months, days, etc., is that so?

        If “we” here means “the GNU project,” – then we already do that;
        check lib/strftime.c, for instance.

        Naturally, when (and if) implemented, such utilities could very
        well be used outside of Emacs.

i386  $ LC_ALL=C date --date=2040-01-01 
date: invalid date `2040-01-01'

amd64 $ LC_ALL=C date --date=2040-01-01 
Sun Jan  1 00:00:00 UTC 2040

[…]

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A