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

[Eli Zaretskii]

> From: Ivan Shmakov <ivan@siamics.net>
> Date: Tue, 09 Dec 2014 19:07:14 +0000
> 
> >>>>> 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.

It will try.

>  >>> 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.

Imagine you are already in the year 2038.  That's the purpose of this
discussion, right?

>  >> 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.

It relies on libc for its job.