unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* What were the Emacs versions with dates limited to 1970 .. 2037 year range?
@ 2022-06-12  9:13 Ihor Radchenko
  2022-06-12  9:22 ` Eli Zaretskii
  0 siblings, 1 reply; 13+ messages in thread
From: Ihor Radchenko @ 2022-06-12  9:13 UTC (permalink / raw)
  To: emacs-devel

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




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: What were the Emacs versions with dates limited to 1970 .. 2037 year range?
  2022-06-12  9:13 What were the Emacs versions with dates limited to 1970 .. 2037 year range? Ihor Radchenko
@ 2022-06-12  9:22 ` Eli Zaretskii
  2022-06-12  9:51   ` Ihor Radchenko
  0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2022-06-12  9:22 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: What were the Emacs versions with dates limited to 1970 .. 2037 year range?
  2022-06-12  9:22 ` Eli Zaretskii
@ 2022-06-12  9:51   ` Ihor Radchenko
  2022-06-12 10:00     ` Eli Zaretskii
  0 siblings, 1 reply; 13+ messages in thread
From: Ihor Radchenko @ 2022-06-12  9:51 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: What were the Emacs versions with dates limited to 1970 .. 2037 year range?
  2022-06-12  9:51   ` Ihor Radchenko
@ 2022-06-12 10:00     ` Eli Zaretskii
  2022-06-12 14:21       ` Stefan Monnier
  0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2022-06-12 10:00 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: What were the Emacs versions with dates limited to 1970 .. 2037 year range?
  2022-06-12 10:00     ` Eli Zaretskii
@ 2022-06-12 14:21       ` Stefan Monnier
  2022-06-12 14:41         ` Eli Zaretskii
  0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2022-06-12 14:21 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Ihor Radchenko, emacs-devel

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




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: What were the Emacs versions with dates limited to 1970 .. 2037 year range?
  2022-06-12 14:21       ` Stefan Monnier
@ 2022-06-12 14:41         ` Eli Zaretskii
  2022-06-13  0:30           ` Po Lu
  0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2022-06-12 14:41 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: yantar92, emacs-devel

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



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: What were the Emacs versions with dates limited to 1970 .. 2037 year range?
  2022-06-12 14:41         ` Eli Zaretskii
@ 2022-06-13  0:30           ` Po Lu
  2022-06-13  2:37             ` Eli Zaretskii
  0 siblings, 1 reply; 13+ messages in thread
From: Po Lu @ 2022-06-13  0:30 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Stefan Monnier, yantar92, emacs-devel

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.



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: What were the Emacs versions with dates limited to 1970 .. 2037 year range?
  2022-06-13  0:30           ` Po Lu
@ 2022-06-13  2:37             ` Eli Zaretskii
  2022-06-13  9:25               ` Stefan Kangas
  2022-06-13 13:19               ` Stefan Monnier
  0 siblings, 2 replies; 13+ messages in thread
From: Eli Zaretskii @ 2022-06-13  2:37 UTC (permalink / raw)
  To: Po Lu; +Cc: monnier, yantar92, emacs-devel

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



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: What were the Emacs versions with dates limited to 1970 .. 2037 year range?
  2022-06-13  2:37             ` Eli Zaretskii
@ 2022-06-13  9:25               ` Stefan Kangas
  2022-06-13 11:49                 ` Eli Zaretskii
  2022-06-13 13:19               ` Stefan Monnier
  1 sibling, 1 reply; 13+ messages in thread
From: Stefan Kangas @ 2022-06-13  9:25 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Po Lu, Stefan Monnier, Ihor Radchenko, Emacs developers

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



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: What were the Emacs versions with dates limited to 1970 .. 2037 year range?
  2022-06-13  9:25               ` Stefan Kangas
@ 2022-06-13 11:49                 ` Eli Zaretskii
  0 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2022-06-13 11:49 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: luangruo, monnier, yantar92, emacs-devel

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



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: What were the Emacs versions with dates limited to 1970 .. 2037 year range?
  2022-06-13  2:37             ` Eli Zaretskii
  2022-06-13  9:25               ` Stefan Kangas
@ 2022-06-13 13:19               ` Stefan Monnier
  2022-06-13 13:29                 ` Eli Zaretskii
  1 sibling, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2022-06-13 13:19 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Po Lu, yantar92, emacs-devel

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




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: What were the Emacs versions with dates limited to 1970 .. 2037 year range?
  2022-06-13 13:19               ` Stefan Monnier
@ 2022-06-13 13:29                 ` Eli Zaretskii
  2022-06-13 16:40                   ` Stefan Monnier
  0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2022-06-13 13:29 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: luangruo, yantar92, emacs-devel

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



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: What were the Emacs versions with dates limited to 1970 .. 2037 year range?
  2022-06-13 13:29                 ` Eli Zaretskii
@ 2022-06-13 16:40                   ` Stefan Monnier
  0 siblings, 0 replies; 13+ messages in thread
From: Stefan Monnier @ 2022-06-13 16:40 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: luangruo, yantar92, emacs-devel

> 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




^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2022-06-13 16:40 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-12  9:13 What were the Emacs versions with dates limited to 1970 .. 2037 year range? Ihor Radchenko
2022-06-12  9:22 ` Eli Zaretskii
2022-06-12  9:51   ` Ihor Radchenko
2022-06-12 10:00     ` Eli Zaretskii
2022-06-12 14:21       ` Stefan Monnier
2022-06-12 14:41         ` Eli Zaretskii
2022-06-13  0:30           ` Po Lu
2022-06-13  2:37             ` Eli Zaretskii
2022-06-13  9:25               ` Stefan Kangas
2022-06-13 11:49                 ` Eli Zaretskii
2022-06-13 13:19               ` Stefan Monnier
2022-06-13 13:29                 ` Eli Zaretskii
2022-06-13 16:40                   ` Stefan Monnier

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).