What were the Emacs versions with dates limited to 1970 .. 2037 year range?

What were the Emacs versions with dates limited to 1970 .. 2037 year range?

[Ihor Radchenko]

Hi,

Org mode currently supports an old workaround for 32-bit year range
limitation:

org-read-date-force-compatible-dates docstring:

> Should date/time prompt force dates that are guaranteed to work in Emacs?
> 
> Depending on the system Emacs is running on, certain dates cannot
> be represented with the type used internally to represent time.
> Dates between 1970-1-1 and 2038-1-1 can always be represented
> correctly.  Some systems allow for earlier dates, some for later,
> some for both.  One way to find out is to insert any date into an
> Org buffer, putting the cursor on the year and hitting S-up and
> S-down to test the range.

The workaround has been introduced about 11 years ago.

Could anyone tell if this issue is still present in Emacs 25 or newer or
maybe on some OS?

Best,
Ihor

Re: What were the Emacs versions with dates limited to 1970 .. 2037 year range?

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Date: Sun, 12 Jun 2022 17:13:25 +0800
> 
> Org mode currently supports an old workaround for 32-bit year range
> limitation:
> 
> org-read-date-force-compatible-dates docstring:
> 
> > Should date/time prompt force dates that are guaranteed to work in Emacs?
> > 
> > Depending on the system Emacs is running on, certain dates cannot
> > be represented with the type used internally to represent time.
> > Dates between 1970-1-1 and 2038-1-1 can always be represented
> > correctly.  Some systems allow for earlier dates, some for later,
> > some for both.  One way to find out is to insert any date into an
> > Org buffer, putting the cursor on the year and hitting S-up and
> > S-down to test the range.
> 
> The workaround has been introduced about 11 years ago.
> 
> Could anyone tell if this issue is still present in Emacs 25 or newer or
> maybe on some OS?

Any 32-bit build of Emacs is potentially prone to this problem,
depending on what time-related APIs it is using.  If time_t is a
32-bit type, this problem will still exist.

Re: What were the Emacs versions with dates limited to 1970 .. 2037 year range?

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> The workaround has been introduced about 11 years ago.
>> 
>> Could anyone tell if this issue is still present in Emacs 25 or newer or
>> maybe on some OS?
>
> Any 32-bit build of Emacs is potentially prone to this problem,
> depending on what time-related APIs it is using.  If time_t is a
> 32-bit type, this problem will still exist.

Thanks for the clarification!

I am now wondering if it is soon going to be the time to do something
about it. 2037 is getting closer and the 32-bit limitation may become a
real issue for the 32-bit Emacs builds.

Best,
Ihor

Re: What were the Emacs versions with dates limited to 1970 .. 2037 year range?

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 12 Jun 2022 17:51:29 +0800
> 
> > Any 32-bit build of Emacs is potentially prone to this problem,
> > depending on what time-related APIs it is using.  If time_t is a
> > 32-bit type, this problem will still exist.
> 
> Thanks for the clarification!
> 
> I am now wondering if it is soon going to be the time to do something
> about it. 2037 is getting closer and the 32-bit limitation may become a
> real issue for the 32-bit Emacs builds.

Yes, at some point in the not-so-distant future we will have to face
the issue.

Re: What were the Emacs versions with dates limited to 1970 .. 2037 year range?

[Stefan Monnier]

Eli Zaretskii [2022-06-12 13:00:57] wrote:
>> > Any 32-bit build of Emacs is potentially prone to this problem,
>> > depending on what time-related APIs it is using.  If time_t is a
>> > 32-bit type, this problem will still exist.
>> 
>> Thanks for the clarification!
>> 
>> I am now wondering if it is soon going to be the time to do something
>> about it. 2037 is getting closer and the 32-bit limitation may become a
>> real issue for the 32-bit Emacs builds.
>
> Yes, at some point in the not-so-distant future we will have to face
> the issue.

I thought there was nothing to be done on our side: we only suffer from
the limitations that are imposed by the libc (and only when the value
needs to be passed to libc), and as soon as the underlying OS/libc is
updated to avoid those problems, the problem also disappears in Emacs.


        Stefan

Re: What were the Emacs versions with dates limited to 1970 .. 2037 year range?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Ihor Radchenko <yantar92@gmail.com>,  emacs-devel@gnu.org
> Date: Sun, 12 Jun 2022 10:21:39 -0400
> 
> Eli Zaretskii [2022-06-12 13:00:57] wrote:
> >> > Any 32-bit build of Emacs is potentially prone to this problem,
> >> > depending on what time-related APIs it is using.  If time_t is a
> >> > 32-bit type, this problem will still exist.
> >> 
> >> Thanks for the clarification!
> >> 
> >> I am now wondering if it is soon going to be the time to do something
> >> about it. 2037 is getting closer and the 32-bit limitation may become a
> >> real issue for the 32-bit Emacs builds.
> >
> > Yes, at some point in the not-so-distant future we will have to face
> > the issue.
> 
> I thought there was nothing to be done on our side: we only suffer from
> the limitations that are imposed by the libc (and only when the value
> needs to be passed to libc), and as soon as the underlying OS/libc is
> updated to avoid those problems, the problem also disappears in Emacs.

That's true, but we will have to at least say something about dropping
support for libc's that don't.  Or something.

Re: What were the Emacs versions with dates limited to 1970 .. 2037 year range?

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> That's true, but we will have to at least say something about dropping
> support for libc's that don't.  Or something.

Come 2037, the systems with unfixed libc's will automatically become
obsolete.  We won't have to do anything.

Re: What were the Emacs versions with dates limited to 1970 .. 2037 year range?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  yantar92@gmail.com,
>   emacs-devel@gnu.org
> Date: Mon, 13 Jun 2022 08:30:15 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That's true, but we will have to at least say something about dropping
> > support for libc's that don't.  Or something.
> 
> Come 2037, the systems with unfixed libc's will automatically become
> obsolete.  We won't have to do anything.

Emacs compiled with those obsolete libc versions can be moved to a
newer system, and will generally still continue working.  So the
system can still be alive, but such an old-compiled Emacs on that
system will die.  We will need at least to mention that somewhere.

Re: What were the Emacs versions with dates limited to 1970 .. 2037 year range?

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Emacs compiled with those obsolete libc versions can be moved to a
> newer system, and will generally still continue working.  So the
> system can still be alive, but such an old-compiled Emacs on that
> system will die.  We will need at least to mention that somewhere.

Would it be worth writing an entry in the FAQ?  (I'm not volunteering:
I don't know enough to write it.)

Re: What were the Emacs versions with dates limited to 1970 .. 2037 year range?

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Mon, 13 Jun 2022 11:25:45 +0200
> Cc: Po Lu <luangruo@yahoo.com>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	Ihor Radchenko <yantar92@gmail.com>, Emacs developers <emacs-devel@gnu.org>
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Emacs compiled with those obsolete libc versions can be moved to a
> > newer system, and will generally still continue working.  So the
> > system can still be alive, but such an old-compiled Emacs on that
> > system will die.  We will need at least to mention that somewhere.
> 
> Would it be worth writing an entry in the FAQ?  (I'm not volunteering:
> I don't know enough to write it.)

If someone knows what and how to write (I don't), I think this could
be a useful addition to the FAQ.

Re: What were the Emacs versions with dates limited to 1970 .. 2037 year range?

[Stefan Monnier]

Eli Zaretskii [2022-06-13 05:37:00] wrote:
>> Come 2037, the systems with unfixed libc's will automatically become
>> obsolete.  We won't have to do anything.
> Emacs compiled with those obsolete libc versions can be moved to a
> newer system, and will generally still continue working.

I don't think so, unless they come with two different `libc`s, in which
case those applications using the newer `libc` might still work and
those with the old `libc` won't, but even so users of such a system will
presumably know that those programs using the old `libc` need to be run
in a specialized environment with a bogus time or something like that.

The argument is that whatever happens to Emacs will also happen to ll
other programs using that same `libc`, so Emacs doesn't really need to
say anything.


        Stefan

Re: What were the Emacs versions with dates limited to 1970 .. 2037 year range?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Po Lu <luangruo@yahoo.com>,  yantar92@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 13 Jun 2022 09:19:48 -0400
> 
> Eli Zaretskii [2022-06-13 05:37:00] wrote:
> >> Come 2037, the systems with unfixed libc's will automatically become
> >> obsolete.  We won't have to do anything.
> > Emacs compiled with those obsolete libc versions can be moved to a
> > newer system, and will generally still continue working.
> 
> I don't think so, unless they come with two different `libc`s, in which
> case those applications using the newer `libc` might still work and
> those with the old `libc` won't, but even so users of such a system will
> presumably know that those programs using the old `libc` need to be run
> in a specialized environment with a bogus time or something like that.

You evidently think about systems where libc is a single shared
library, and the _only_ library used by Emacs where the 32-bit time_t
type is used.  Think more generally: what if some of what you consider
'libc' was linked statically into Emacs, and what if some of the other
libraries Emacs uses use 32-bit time type?

> The argument is that whatever happens to Emacs will also happen to ll
> other programs using that same `libc`

That is not necessarily so.

Re: What were the Emacs versions with dates limited to 1970 .. 2037 year range?

[Stefan Monnier]

> You evidently think about systems where libc is a single shared
> library, and the _only_ library used by Emacs where the 32-bit time_t
> type is used.  Think more generally: what if some of what you consider
> 'libc' was linked statically into Emacs, and what if some of the other
> libraries Emacs uses use 32-bit time type?

I tried but my head rebooted along the way, I think it's a safety
mechanism to avoid an explosion.


        Stefan