bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#19302: 24.4.51; `date-to-time' fails after 2038
Date: Tue, 09 Dec 2014 21:48:51 +0200

> From: Ivan Shmakov <address@hidden>
> Date: Tue, 09 Dec 2014 19:07:14 +0000
> 
> >>>>> Eli Zaretskii <address@hidden> writes:
> >>>>> From: Lars Magne Ingebrigtsen   Date: Tue, 09 Dec 2014 19:31:20 +0100
> >>>>> Eli Zaretskii <address@hidden> 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]