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

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

[Gabriel]

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

The function `date-to-time' will fail if the argument if after
19-Jan-2038 03:14:07 GMT.

It doesn't seem documented everywhere (unless the 'Year 2038 problem' is
assumed knowledge).

I don't think I can actually fix it. But I wrote a little patch to at
least make it clear in the doc string.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Doc fix patch to `date-to-time' --]
[-- Type: text/x-diff, Size: 1436 bytes --]

From c90da02532e7025d6f73f288244f487c77ab9538 Mon Sep 17 00:00:00 2001
From: Gabriel Beauchamp <beauchampgabriel@gmail.com>
Date: Sun, 7 Dec 2014 20:46:30 -0500
Subject: [PATCH] calendar/time-date.el (date-to-time): Doc fix.

---
 lisp/ChangeLog             | 4 ++++
 lisp/calendar/time-date.el | 4 +++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/lisp/ChangeLog b/lisp/ChangeLog
index a1d60d1..30e704f 100644
--- a/lisp/ChangeLog
+++ b/lisp/ChangeLog
@@ -1,3 +1,7 @@
+2014-12-08  Gabriel Beauchamp <beauchampgabriel@gmail.com>
+
+	* calendar/time-date.el (date-to-time): Doc fix.
+
 2014-12-07  Lars Magne Ingebrigtsen  <larsi@gnus.org>
 
 	* net/eww.el (eww-follow-link): Revert prefix behaviour to
diff --git a/lisp/calendar/time-date.el b/lisp/calendar/time-date.el
index e7a8cc7..4e67adc 100644
--- a/lisp/calendar/time-date.el
+++ b/lisp/calendar/time-date.el
@@ -146,7 +146,9 @@ it is assumed that PICO was omitted and should be treated as zero."
 ;; values.  timezone-make-date-arpa-standard should help.
 (defun date-to-time (date)
   "Parse a string DATE that represents a date-time and return a time value.
-If DATE lacks timezone information, GMT is assumed."
+If DATE lacks timezone information, GMT is assumed.
+If DATE is after 19-Jan-2038 03:14:07 GMT, `date-to-time' will fail
+and raise an error."
   (condition-case err
       (apply 'encode-time (parse-time-string date))
     (error
-- 
1.8.3.2

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

[Lars Magne Ingebrigtsen]

Gabriel <beauchampgabriel@gmail.com> writes:

> The function `date-to-time' will fail if the argument if after
> 19-Jan-2038 03:14:07 GMT.

(date-to-time "Sun, 07 Dec 2345 20:58:36 -0500")
=> (181020 5196)

Are you running a 32-bit Emacs?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Gabriel]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Gabriel <beauchampgabriel@gmail.com> writes:
>
>> The function `date-to-time' will fail if the argument if after
>> 19-Jan-2038 03:14:07 GMT.
>
> (date-to-time "Sun, 07 Dec 2345 20:58:36 -0500")
> => (181020 5196)
>
> Are you running a 32-bit Emacs?

Yes, and 32-bit GNU/Linux.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > (date-to-time "Sun, 07 Dec 2345 20:58:36 -0500")
  > => (181020 5196)

  > Are you running a 32-bit Emacs?

Can we change Emacs so that it uses 64 bits for time values
on all platforms?  Even if there is no system call to GET the time
value in that form, we could still handle it internally that way.
-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

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

[Lars Magne Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

>   > (date-to-time "Sun, 07 Dec 2345 20:58:36 -0500")
>   > => (181020 5196)
>
>   > Are you running a 32-bit Emacs?
>
> Can we change Emacs so that it uses 64 bits for time values
> on all platforms?  Even if there is no system call to GET the time
> value in that form, we could still handle it internally that way.

If I remember correctly, there are OS-es out there that have a 32-bit
time_t?  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > If I remember correctly, there are OS-es out there that have a 32-bit
  > time_t?  

Apparently so -- that is why I suggest making Emacs use 64 bits
even if the operating system uses 32 bits.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

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

[Eli Zaretskii]

> Date: Tue, 09 Dec 2014 06:01:26 -0500
> From: Richard Stallman <rms@gnu.org>
> Cc: 19302@debbugs.gnu.org, beauchampgabriel@gmail.com
> 
>   > If I remember correctly, there are OS-es out there that have a 32-bit
>   > time_t?  
> 
> Apparently so -- that is why I suggest making Emacs use 64 bits
> even if the operating system uses 32 bits.

What do you do with time_t fields of 'struct stat', 'struct timeval',
and other structures used by library functions?  They will still wrap
around.

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

[Ivan Shmakov]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> Date: Tue, 09 Dec 2014 06:01:26 -0500  From: Richard Stallman

 >>> If I remember correctly, there are OS-es out there that have a
 >>> 32-bit time_t?

 >> Apparently so -- that is why I suggest making Emacs use 64 bits even
 >> if the operating system uses 32 bits.

 > What do you do with time_t fields of 'struct stat', 'struct timeval',
 > and other structures used by library functions?  They will still wrap
 > around.

	How would that affect a function whose purpose is not to pass
	such a time value to some library call?

	And when a value /is/ passed to the underlying platform, it can
	be checked if it fits the target type, and the error signalled
	if it doesn’t.

	In the case of date-to-time, the likely culprit is encode-time,
	which is (more or less) a wrapper around mktime ().  Granted,
	Emacs may use Gnulib’s mktime.c, but it doesn’t seem to provide
	a 64-bit variant of mktime () suitable for systems with 32-bit
	time_t, either.

	Thus, the real question is: do we want some kind of time64_t
	support in Gnulib, and if so, who’d volunteer to implement it?

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

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

[Eli Zaretskii]

> From: Ivan Shmakov <ivan@siamics.net>
> Date: Tue, 09 Dec 2014 18:17:59 +0000
> 
>  > What do you do with time_t fields of 'struct stat', 'struct timeval',
>  > and other structures used by library functions?  They will still wrap
>  > around.
> 
> 	How would that affect a function whose purpose is not to pass
> 	such a time value to some library call?
> 
> 	And when a value /is/ passed to the underlying platform, it can
> 	be checked if it fits the target type, and the error signalled
> 	if it doesn’t.

So such an Emacs will be broken anyway after 2038, because it will be
unable to interpret file attributes, use interval timers, etc.

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

[Lars Magne Ingebrigtsen]

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, use interval timers, etc.

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

It would be nice if those headers worked on 32-bit Emacsen, but on the
other hand, there's very little reason to use a 32-bit OS these days, so
it's not really a pressing issue.  And it gets less pressing each year.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: Ivan Shmakov <ivan@siamics.net>,  19302@debbugs.gnu.org
> 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, use interval timers, etc.
> 
> 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, etyc., is that so?

> It would be nice if those headers worked on 32-bit Emacsen, but on the
> other hand, there's very little reason to use a 32-bit OS these days, so
> it's not really a pressing issue.  And it gets less pressing each year.

Indeed.

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

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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, etyc., is that so?

Not at all.  I'm just explaining what the use case it.  My solution
would be to just document this ("Emacs does not support dates further
into the future than 2038 on OS-es with 32-bit time_t") and move on.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: 19302@debbugs.gnu.org,  ivan@siamics.net
> Date: Tue, 09 Dec 2014 20:01:22 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 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, etyc., is that so?
> 
> Not at all.  I'm just explaining what the use case it.

I understood, and even agreed.

> My solution would be to just document this ("Emacs does not support
> dates further into the future than 2038 on OS-es with 32-bit
> time_t") and move on.

Yes.

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

[Gabriel]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
>> My solution would be to just document this ("Emacs does not support
>> dates further into the future than 2038 on OS-es with 32-bit
>> time_t") and move on.
>
> Yes.

I'd be willing to try and document that.
I thought `date-to-time' would have been the right place to do that.
(Given the backtrace I had stopped there)
But I could write it in the Elisp manual too.

And write a patch and send it to emacs-devel?

(Sorry, I need pointers for my first contribution)

Thanks

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

[Eli Zaretskii]

> From: Gabriel <beauchampgabriel@gmail.com>
> Date: Tue, 09 Dec 2014 19:41:58 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> >> My solution would be to just document this ("Emacs does not support
> >> dates further into the future than 2038 on OS-es with 32-bit
> >> time_t") and move on.
> >
> > Yes.
> 
> I'd be willing to try and document that.

Thank you.

> I thought `date-to-time' would have been the right place to do that.
> (Given the backtrace I had stopped there)
> But I could write it in the Elisp manual too.

If you have time, please do both.

> And write a patch and send it to emacs-devel?

You could post it to this thread/bug report.

> (Sorry, I need pointers for my first contribution)

No need to apologize.  Thanks in advance.

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

[Gabriel]

[-- Attachment #1: Type: text/plain, Size: 217 bytes --]

I made only one commit, since it's basically the same text in both.

And, reading a bit more on the manual.
I saw that in "(elisp) Time Conversion" it's actually documented that
the time will fail on 32-bit.

Thanks


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: date-to-time doc fixes --]
[-- Type: text/x-diff, Size: 2403 bytes --]

From 27ff288c14aebce442b72c7e4d433d7cfff37f85 Mon Sep 17 00:00:00 2001
From: Gabriel Beauchamp <beauchampgabriel@gmail.com>
Date: Wed, 10 Dec 2014 18:18:16 -0500
Subject: [PATCH] Doc fixes.

    * calendar/time-date.el (date-to-time): Doc fix.
    * os.texi (Time Parsing): Doc fix.
---
 doc/lispref/ChangeLog      | 4 ++++
 doc/lispref/os.texi        | 2 ++
 lisp/ChangeLog             | 4 ++++
 lisp/calendar/time-date.el | 3 ++-
 4 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/doc/lispref/ChangeLog b/doc/lispref/ChangeLog
index e7b5606..0624bee 100644
--- a/doc/lispref/ChangeLog
+++ b/doc/lispref/ChangeLog
@@ -1,3 +1,7 @@
+2014-12-10  Gabriel  <beauchampgabriel@gmail.com>
+
+	* os.texi (Time Parsing): Doc fix.
+
 2014-12-09  Lars Magne Ingebrigtsen  <larsi@gnus.org>
 
 	* files.texi (Contents of Directories): Document
diff --git a/doc/lispref/os.texi b/doc/lispref/os.texi
index b709447..1936bdf 100644
--- a/doc/lispref/os.texi
+++ b/doc/lispref/os.texi
@@ -1422,6 +1422,8 @@ Time values are lists of two to four integers (@pxref{Time of Day}).
 @defun date-to-time string
 This function parses the time-string @var{string} and returns the
 corresponding time value.
+On 32-bit systems, this function will fail for @var{string}
+after 19-Jan-2038.
 @end defun
 
 @defun format-time-string format-string &optional time-value universal
diff --git a/lisp/ChangeLog b/lisp/ChangeLog
index e65835c..39727d9 100644
--- a/lisp/ChangeLog
+++ b/lisp/ChangeLog
@@ -1,3 +1,7 @@
+2014-12-10  Gabriel  <beauchampgabriel@gmail.com>
+
+	* calendar/time-date.el (date-to-time): Doc fix.
+
 2014-12-10  Artur Malabarba  <bruce.connor.am@gmail.com>
 
 	* let-alist.el: Add new package and macro.
diff --git a/lisp/calendar/time-date.el b/lisp/calendar/time-date.el
index e7a8cc7..e77d648 100644
--- a/lisp/calendar/time-date.el
+++ b/lisp/calendar/time-date.el
@@ -146,7 +146,8 @@ it is assumed that PICO was omitted and should be treated as zero."
 ;; values.  timezone-make-date-arpa-standard should help.
 (defun date-to-time (date)
   "Parse a string DATE that represents a date-time and return a time value.
-If DATE lacks timezone information, GMT is assumed."
+If DATE lacks timezone information, GMT is assumed.
+On 32-bit systems, this function will fail for DATE after 19-Jan-2038."
   (condition-case err
       (apply 'encode-time (parse-time-string date))
     (error
-- 
1.8.3.2

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

[Andreas Schwab]

Gabriel <beauchampgabriel@gmail.com> writes:

> diff --git a/doc/lispref/os.texi b/doc/lispref/os.texi
> index b709447..1936bdf 100644
> --- a/doc/lispref/os.texi
> +++ b/doc/lispref/os.texi
> @@ -1422,6 +1422,8 @@ Time values are lists of two to four integers (@pxref{Time of Day}).
>  @defun date-to-time string
>  This function parses the time-string @var{string} and returns the
>  corresponding time value.
> +On 32-bit systems, this function will fail for @var{string}
> +after 19-Jan-2038.

This is not true.  It may last up to 2106-02-07.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

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

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Not at all.  I'm just explaining what the use case it.  My solution
> would be to just document this ("Emacs does not support dates further
> into the future than 2038 on OS-es with 32-bit time_t") and move on.

A 32-bit time_t can support dates upto the year 2106 (but would no
longer support dates before 1970).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

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.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It would be nice if those headers worked on 32-bit Emacsen, but on the
  > other hand, there's very little reason to use a 32-bit OS these days, so
  > it's not really a pressing issue.  And it gets less pressing each year.

To get rid of 32-bit OS's soon would be a fine solution.

Gabriel <beauchampgabriel@gmail.com>, can you tell us why you
still use one?  If you have a good reason, it might indicate
some problem we should try to solve.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

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

[Gabriel]

Richard Stallman <rms@gnu.org> writes:

> Gabriel <beauchampgabriel@gmail.com>, can you tell us why you
> still use one?  If you have a good reason, it might indicate
> some problem we should try to solve.

Well, I have an quite old laptop and, I tend to have lots of problems
with it.
So I stuck with a 32-bit that 'just works'.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Well, I have an quite old laptop and, I tend to have lots of problems
  > with it.
  > So I stuck with a 32-bit that 'just works'.

I understand your decision -- but if this is the only reason people
are still using 32-bit systems, we can just let them disappear.

I wonder if a Glibc upgrade could fix this for you, as someone
suggested.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

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

[Gabriel]

Richard Stallman <rms@gnu.org> writes:

> I understand your decision -- but if this is the only reason people
> are still using 32-bit systems, we can just let them disappear.

Indeed.

> I wonder if a Glibc upgrade could fix this for you, as someone
> suggested.

Maybe, however, I'll think I'll just try and go for a 64-bit system when
I'll have the time.
Which should just be easier.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Apparently so -- that is why I suggest making Emacs use 64 bits
  > > even if the operating system uses 32 bits.

  > What do you do with time_t fields of 'struct stat', 'struct timeval',
  > and other structures used by library functions?  They will still wrap
  > around.

Emacs can't fix the operating system, to be sure.  But it could use 64
bits for time values when not passing them through the system.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

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

[Stefan Monnier]

> Apparently so -- that is why I suggest making Emacs use 64 bits
> even if the operating system uses 32 bits.

This problem will affect all applications under such OSes, so fixing it
in Emacs won't be sufficient.  Emacs should not go out of its way to
work around OS limitations.


        Stefan

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Apparently so -- that is why I suggest making Emacs use 64 bits
  > > even if the operating system uses 32 bits.

  > This problem will affect all applications under such OSes, so fixing it
  > in Emacs won't be sufficient.

That's true.  However, Emacs will get wrong results today on those systems,
if operating on future times.  We may as well make that problem go away.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

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

[Stefan Monnier]

> That's true.  However, Emacs will get wrong results today on those systems,

Yes, Emacs along with all other applications on those systems.

> We may as well make that problem go away.

I agree, but not by making Emacs do heroic hacks, instead we can make
the problem go away by telling the user to update his C library.


        Stefan

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I agree, but not by making Emacs do heroic hacks, instead we can make
  > the problem go away by telling the user to update his C library.

What C library version fixes this?

Should Emacs urge people generally to make that upgrade?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

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

[Stefan Monnier]

>> I agree, but not by making Emacs do heroic hacks, instead we can make
>> the problem go away by telling the user to update his C library.
> What C library version fixes this?

I don't know.  But as long as the problem is not sufficiently important
to fix it in the C library, I don't see why we should fix it in Emacs.


        Stefan

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >> I agree, but not by making Emacs do heroic hacks, instead we can make
  > >> the problem go away by telling the user to update his C library.
  > > What C library version fixes this?

  > I don't know.  But as long as the problem is not sufficiently important
  > to fix it in the C library, I don't see why we should fix it in Emacs.

Does anyone know what C library version fixes this?
Whoever said it can be fixed that way -- do you know?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

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

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> I agree, but not by making Emacs do heroic hacks, instead we can make
>>> the problem go away by telling the user to update his C library.
>> What C library version fixes this?
>
> I don't know.  But as long as the problem is not sufficiently important
> to fix it in the C library, I don't see why we should fix it in Emacs.

It seems like the glibc maintainers are still working on a fix.  Here
are two relevant links for reference:

https://sourceware.org/glibc/wiki/Y2038ProofnessDesign
https://sourceware.org/ml/libc-alpha/2019-07/msg00256.html

Best regards,
Stefan Kangas

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

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> I agree, but not by making Emacs do heroic hacks, instead we can make
>>> the problem go away by telling the user to update his C library.
>> What C library version fixes this?
>
> I don't know.  But as long as the problem is not sufficiently important
> to fix it in the C library, I don't see why we should fix it in Emacs.

I agree.  Does anyone object to closing this as wontfix?

Best regards,
Stefan Kangas

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

[Stefan Monnier]

>>>> I agree, but not by making Emacs do heroic hacks, instead we can make
>>>> the problem go away by telling the user to update his C library.
>>> What C library version fixes this?
>> I don't know.  But as long as the problem is not sufficiently important
>> to fix it in the C library, I don't see why we should fix it in Emacs.
> I agree.  Does anyone object to closing this as wontfix?

Side note: IIUC glibc now has something working and distributions like
Debian are now trying to figure out how to go about incorporating it
(since it expands time_t to 64bit on 32bit systems, forcing an
ABI-incompatible change which can create more ABI-incompatible changes
in libraries that include a time_t in their API).


        Stefan

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

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>>> I agree, but not by making Emacs do heroic hacks, instead we can make
>>>>> the problem go away by telling the user to update his C library.
>>>> What C library version fixes this?
>>> I don't know.  But as long as the problem is not sufficiently important
>>> to fix it in the C library, I don't see why we should fix it in Emacs.
>> I agree.  Does anyone object to closing this as wontfix?
>
> Side note: IIUC glibc now has something working and distributions like
> Debian are now trying to figure out how to go about incorporating it
> (since it expands time_t to 64bit on 32bit systems, forcing an
> ABI-incompatible change which can create more ABI-incompatible changes
> in libraries that include a time_t in their API).

Interesting.  I found the following article regarding Debian:
https://lwn.net/Articles/812767/

If I understand correctly, we will have to make some accomodations
once this is fully merged, according to the current proposal.[1]  The
glibc page, last edited 2018-09-19, says:

    e.g. the 64-bit implementation of clock_gettime would be named
    clock_gettime64.

That seems to also be the content of a series of proposed patches
currently being discussed on the glibc mailing list.[2]

In summary, we might want to keep this bug report open until we have
implemented support for the new types.

Best regards,
Stefan Kangas

Footnotes: 
[1] https://sourceware.org/glibc/wiki/Y2038ProofnessDesign

[2] See for example:
https://sourceware.org/ml/libc-alpha/2020-02/msg00873.html

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

[Stefan Monnier]

>     e.g. the 64-bit implementation of clock_gettime would be named
>     clock_gettime64.

IIUC this is likely going to be a hidden internal detail.

> In summary, we might want to keep this bug report open until we have
> implemented support for the new types.

I think it'll make more sense to open a new report if/when the need
shows up.


        Stefan

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

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I think it'll make more sense to open a new report if/when the need
> shows up.

Thanks.  I'm therefore closing the bug now.

Best regards,
Stefan Kangas

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

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I think it'll make more sense to open a new report if/when the need
> shows up.

OK, thanks.  Closing this bug now.

Best regards,
Stefan Kangas