* bug#37974: eww produces "error in process filter: Specified time is not representable"
@ 2019-10-29 0:32 Stuart Little
2019-10-29 4:51 ` Stuart Little
2019-11-01 8:05 ` Paul Eggert
0 siblings, 2 replies; 16+ messages in thread
From: Stuart Little @ 2019-10-29 0:32 UTC (permalink / raw
To: 37974
I am on a Debian 10.1 machine i686. The current Emacs version in this Debian repo is 26.1.
My issue is that
M-x eww RET arxiv.org RET
fails to load the page and produces the error
error in process filter: Specified time is not representable
in the minibuffer. Other websites load fine (e.g. nytimes.com, theguardian.comn, google.com). Others, on the other hand, simply silently time out: duckduckgo.com and thenation.com behave this way (the minibuffer reports 'contacting host' but the page never loads).
Everything loads fine on an Arch Linux x86_64 machine running Emacs 26.3 as well as an Android 9 phone running an ARM version of Emacs 26.3 in a terminal emulator (Termux), so it is not a network issue.
Additionally, a separate machine running Linux Mint 19.2 an Emacs 25.2.2 loads arxiv.org without issue.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#37974: eww produces "error in process filter: Specified time is not representable"
2019-10-29 0:32 bug#37974: eww produces "error in process filter: Specified time is not representable" Stuart Little
@ 2019-10-29 4:51 ` Stuart Little
2019-10-29 10:25 ` Stuart Little
2019-11-01 8:05 ` Paul Eggert
1 sibling, 1 reply; 16+ messages in thread
From: Stuart Little @ 2019-10-29 4:51 UTC (permalink / raw
To: 37974
Apologies for the uninformative message below. I know slightly more now.
Setting debug-on-error and running
M-x eww RET arxiv.org RET
again produces the following trace:
--- cut here ---
Debugger entered--Lisp error: (error "Specified time is not representable")
format-time-string("%a %b %d %H:%M:%S %Y GMT" (38427 52290 103040 624000) t)
url-cookie-handle-set-cookie("browser=68.133.6.220.1572324160979722; path=/; max-age=946080000; domain=.arxiv.org")
url-http-handle-cookies()
url-http-parse-headers()
url-http-chunked-encoding-after-change-function(7029 7034 5)
url-http-generic-filter(#<process arxiv.org<1>> "0\015\n\015\n")
read-event(nil t 2)
sit-for(2)
execute-extended-command(nil "eww" "eww")
funcall-interactively(execute-extended-command nil "eww" "eww")
call-interactively(execute-extended-command nil nil)
command-execute(execute-extended-command)
--- done ---
This told me the problem was with the url-cookie-handle-set-cookie function; specifically, with the format-time-string directive therein. I tried to fiddle with it to confirm. Indeed, replacing the relevant if-then-else clause
--- cut ---
(if (and max-age (string-match "\\`-?[0-9]+\\'" max-age))
(setq expires (format-time-string "%a %b %d %H:%M:%S %Y GMT"
(time-add nil (read max-age))
t))
(setq expires (cdr-safe (assoc-string "expires" args t))))
--- done ---
therein with just the else branch
(setq expires (cdr-safe (assoc-string "expires" args t)))
resolves the issue. arxiv.org loads fine with the redefined url-cookie-handle-set-cookie function.
On Mon, Oct 28, 2019 at 08:32:45PM -0400, Stuart Little wrote:
> I am on a Debian 10.1 machine i686. The current Emacs version in this Debian repo is 26.1.
>
> My issue is that
>
> M-x eww RET arxiv.org RET
>
> fails to load the page and produces the error
>
> error in process filter: Specified time is not representable
>
> in the minibuffer. Other websites load fine (e.g. nytimes.com, theguardian.comn, google.com). Others, on the other hand, simply silently time out: duckduckgo.com and thenation.com behave this way (the minibuffer reports 'contacting host' but the page never loads).
>
> Everything loads fine on an Arch Linux x86_64 machine running Emacs 26.3 as well as an Android 9 phone running an ARM version of Emacs 26.3 in a terminal emulator (Termux), so it is not a network issue.
>
> Additionally, a separate machine running Linux Mint 19.2 an Emacs 25.2.2 loads arxiv.org without issue.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#37974: eww produces "error in process filter: Specified time is not representable"
2019-10-29 4:51 ` Stuart Little
@ 2019-10-29 10:25 ` Stuart Little
2019-10-29 12:05 ` A.C.
0 siblings, 1 reply; 16+ messages in thread
From: Stuart Little @ 2019-10-29 10:25 UTC (permalink / raw
To: 37974
I believe I've isolated this as far as I can: the systems running Emacs 26.1 and 26.3 respectively have identical code for the function 'url-cookie-handle-set-cookie', so that on its own is not the problem. Rather, 'format-time-string' works fine on the x86_64 Arch Linux system but not the Debian i686:
On the former, evaluating
(format-time-string "%a %b %d %H:%M:%S %Y GMT" '(38428 5755 960288 499000))
in the *scratch* buffer echoes "Thu Oct 21 05:59:23 2049 GMT". On the other hand, evaluating the exact same function in the *scratch* buffer on the Debian system produces the error "Specified time is not representable".
On Tue, Oct 29, 2019 at 12:51:02AM -0400, Stuart Little wrote:
> Apologies for the uninformative message below. I know slightly more now.
>
> Setting debug-on-error and running
>
> M-x eww RET arxiv.org RET
>
> again produces the following trace:
>
> --- cut here ---
>
> Debugger entered--Lisp error: (error "Specified time is not representable")
> format-time-string("%a %b %d %H:%M:%S %Y GMT" (38427 52290 103040 624000) t)
> url-cookie-handle-set-cookie("browser=68.133.6.220.1572324160979722; path=/; max-age=946080000; domain=.arxiv.org")
> url-http-handle-cookies()
> url-http-parse-headers()
> url-http-chunked-encoding-after-change-function(7029 7034 5)
> url-http-generic-filter(#<process arxiv.org<1>> "0\015\n\015\n")
> read-event(nil t 2)
> sit-for(2)
> execute-extended-command(nil "eww" "eww")
> funcall-interactively(execute-extended-command nil "eww" "eww")
> call-interactively(execute-extended-command nil nil)
> command-execute(execute-extended-command)
>
> --- done ---
>
> This told me the problem was with the url-cookie-handle-set-cookie function; specifically, with the format-time-string directive therein. I tried to fiddle with it to confirm. Indeed, replacing the relevant if-then-else clause
>
> --- cut ---
>
> (if (and max-age (string-match "\\`-?[0-9]+\\'" max-age))
> (setq expires (format-time-string "%a %b %d %H:%M:%S %Y GMT"
> (time-add nil (read max-age))
> t))
> (setq expires (cdr-safe (assoc-string "expires" args t))))
>
> --- done ---
>
> therein with just the else branch
>
> (setq expires (cdr-safe (assoc-string "expires" args t)))
>
> resolves the issue. arxiv.org loads fine with the redefined url-cookie-handle-set-cookie function.
>
> On Mon, Oct 28, 2019 at 08:32:45PM -0400, Stuart Little wrote:
> > I am on a Debian 10.1 machine i686. The current Emacs version in this Debian repo is 26.1.
> >
> > My issue is that
> >
> > M-x eww RET arxiv.org RET
> >
> > fails to load the page and produces the error
> >
> > error in process filter: Specified time is not representable
> >
> > in the minibuffer. Other websites load fine (e.g. nytimes.com, theguardian.comn, google.com). Others, on the other hand, simply silently time out: duckduckgo.com and thenation.com behave this way (the minibuffer reports 'contacting host' but the page never loads).
> >
> > Everything loads fine on an Arch Linux x86_64 machine running Emacs 26.3 as well as an Android 9 phone running an ARM version of Emacs 26.3 in a terminal emulator (Termux), so it is not a network issue.
> >
> > Additionally, a separate machine running Linux Mint 19.2 an Emacs 25.2.2 loads arxiv.org without issue.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#37974: eww produces "error in process filter: Specified time is not representable"
2019-10-29 10:25 ` Stuart Little
@ 2019-10-29 12:05 ` A.C.
2019-10-29 12:47 ` Lars Ingebrigtsen
0 siblings, 1 reply; 16+ messages in thread
From: A.C. @ 2019-10-29 12:05 UTC (permalink / raw
To: 37974
[-- Attachment #1: Type: text/plain, Size: 5043 bytes --]
This must be a word-size issue: on *all* systems where
M-x eww RET arxiv.org RET
loads all right the largest n such that *scratch* evaluation of
(format-time-string "%a %b %d %H:%M:%S %Y GMT" (list n 0 0 0))
produces a valid date is
n=1034058169428
(exact same n on two x86_64 machines and an aarch64 Android phone). Also, all of these systems return
$ getconf WORD_BIT
32
$ getconf LONG_BIT
64
On the other hand, the Debian i686 system that doesn't load arxiv.org has a largest valid n of
n=32767=2**15-1
and returns
$ getconf WORD_BIT
32
$ getconf LONG_BIT
32
That's why it chokes on arxiv.org: loading that page attempts
format-time-string("%a %b %d %H:%M:%S %Y GMT" (38428 13130 924849 611000) t)
and 38428 > 32767
I don't know that upgrading to Emacs 26.3 from 26.1 would address this in any way.
On October 29, 2019 6:25:22 AM EDT, Stuart Little <achirvasub@gmail.com> wrote:
>I believe I've isolated this as far as I can: the systems running Emacs
>26.1 and 26.3 respectively have identical code for the function
>'url-cookie-handle-set-cookie', so that on its own is not the problem.
>Rather, 'format-time-string' works fine on the x86_64 Arch Linux system
>but not the Debian i686:
>
>On the former, evaluating
>
>(format-time-string "%a %b %d %H:%M:%S %Y GMT" '(38428 5755 960288
>499000))
>
>in the *scratch* buffer echoes "Thu Oct 21 05:59:23 2049 GMT". On the
>other hand, evaluating the exact same function in the *scratch* buffer
>on the Debian system produces the error "Specified time is not
>representable".
>
>On Tue, Oct 29, 2019 at 12:51:02AM -0400, Stuart Little wrote:
>> Apologies for the uninformative message below. I know slightly more
>now.
>>
>> Setting debug-on-error and running
>>
>> M-x eww RET arxiv.org RET
>>
>> again produces the following trace:
>>
>> --- cut here ---
>>
>> Debugger entered--Lisp error: (error "Specified time is not
>representable")
>
>> format-time-string("%a %b %d %H:%M:%S %Y GMT" (38427 52290 103040
>624000) t)
>>
>url-cookie-handle-set-cookie("browser=68.133.6.220.1572324160979722;
>path=/; max-age=946080000; domain=.arxiv.org")
>> url-http-handle-cookies()
>> url-http-parse-headers()
>> url-http-chunked-encoding-after-change-function(7029 7034 5)
>> url-http-generic-filter(#<process arxiv.org<1>> "0\015\n\015\n")
>> read-event(nil t 2)
>> sit-for(2)
>> execute-extended-command(nil "eww" "eww")
>> funcall-interactively(execute-extended-command nil "eww" "eww")
>> call-interactively(execute-extended-command nil nil)
>> command-execute(execute-extended-command)
>>
>> --- done ---
>>
>> This told me the problem was with the url-cookie-handle-set-cookie
>function; specifically, with the format-time-string directive therein.
>I tried to fiddle with it to confirm. Indeed, replacing the relevant
>if-then-else clause
>>
>> --- cut ---
>>
>> (if (and max-age (string-match "\\`-?[0-9]+\\'" max-age))
>
>> (setq expires (format-time-string "%a %b %d %H:%M:%S %Y GMT"
>
>> (time-add nil (read
>max-age))
>
>> t))
>
>> (setq expires (cdr-safe (assoc-string "expires" args t))))
>>
>> --- done ---
>>
>> therein with just the else branch
>>
>> (setq expires (cdr-safe (assoc-string "expires" args t)))
>>
>> resolves the issue. arxiv.org loads fine with the redefined
>url-cookie-handle-set-cookie function.
>>
>> On Mon, Oct 28, 2019 at 08:32:45PM -0400, Stuart Little wrote:
>> > I am on a Debian 10.1 machine i686. The current Emacs version in
>this Debian repo is 26.1.
>> >
>> > My issue is that
>> >
>> > M-x eww RET arxiv.org RET
>> >
>> > fails to load the page and produces the error
>> >
>> > error in process filter: Specified time is not representable
>> >
>> > in the minibuffer. Other websites load fine (e.g. nytimes.com,
>theguardian.comn, google.com). Others, on the other hand, simply
>silently time out: duckduckgo.com and thenation.com behave this way
>(the minibuffer reports 'contacting host' but the page never loads).
>> >
>> > Everything loads fine on an Arch Linux x86_64 machine running Emacs
>26.3 as well as an Android 9 phone running an ARM version of Emacs 26.3
>in a terminal emulator (Termux), so it is not a network issue.
>> >
>> > Additionally, a separate machine running Linux Mint 19.2 an Emacs
>25.2.2 loads arxiv.org without issue.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
[-- Attachment #2: Type: text/html, Size: 5554 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#37974: eww produces "error in process filter: Specified time is not representable"
2019-10-29 12:05 ` A.C.
@ 2019-10-29 12:47 ` Lars Ingebrigtsen
2019-10-29 14:06 ` A.C.
0 siblings, 1 reply; 16+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-29 12:47 UTC (permalink / raw
To: A.C.; +Cc: 37974
"A.C." <achirvasub@gmail.com> writes:
> On the other hand, the Debian i686 system that doesn't load arxiv.org has a
> largest valid n of
I'm not quite sure I understood the bug report -- are you saying that
this is only an issue on 32-bit systems?
In any case, Emacs 27 has bignum support, so this should hopefully not
be a problem any more. Can you try the test case with the current Emacs
trunk and see whether it's still present?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#37974: eww produces "error in process filter: Specified time is not representable"
2019-10-29 12:47 ` Lars Ingebrigtsen
@ 2019-10-29 14:06 ` A.C.
2019-10-29 14:41 ` A.C.
2019-10-29 21:52 ` Lars Ingebrigtsen
0 siblings, 2 replies; 16+ messages in thread
From: A.C. @ 2019-10-29 14:06 UTC (permalink / raw
To: Lars Ingebrigtsen; +Cc: 37974
[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]
On October 29, 2019 8:47:02 AM EDT, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>"A.C." <achirvasub@gmail.com> writes:
>
>> On the other hand, the Debian i686 system that doesn't load arxiv.org
>has a
>> largest valid n of
>
>I'm not quite sure I understood the bug report -- are you saying that
>this is only an issue on 32-bit systems?
>
I don't have access to enough systems to tell for sure. I do know it's only happening on the one 32-bit system I have access to right now, and also that I hit the problem a while back on 32-bit ARM:
https://github.com/termux/termux-packages/issues/2614
(and have not see the issue on any 64-bit systems)
>In any case, Emacs 27 has bignum support, so this should hopefully not
>be a problem any more. Can you try the test case with the current
>Emacs
>trunk and see whether it's still present?
That will be tough. This 32-bit machine overheats something fierce; I doubt I can even clone the git repo without it dying, let alone compile.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
[-- Attachment #2: Type: text/html, Size: 1261 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#37974: eww produces "error in process filter: Specified time is not representable"
2019-10-29 14:06 ` A.C.
@ 2019-10-29 14:41 ` A.C.
2019-10-29 21:52 ` Lars Ingebrigtsen
1 sibling, 0 replies; 16+ messages in thread
From: A.C. @ 2019-10-29 14:41 UTC (permalink / raw
To: Lars Ingebrigtsen; +Cc: 37974
[-- Attachment #1: Type: text/plain, Size: 2101 bytes --]
OK, so it *is* a 32-bit problem. This is awesome :):
- on my 32-bit system the highest I can go with an error-less format-time-string is
(format-time-string "%a %b %d %H:%M:%S %Y GMT" (list 32767 65535 0 0))
That will give a total of
32767*2**16+65535 = 2147483647 = 2**31-1
seconds from the Unix epoch, i.e. spot-on the year-2038 problem:
https://en.m.wikipedia.org/wiki/Year_2038_problem
- on the other hand, on my 64-bit systems the highest I can go is
(format-time-string "%a %b %d %H:%M:%S %Y GMT" (list 1034058169428 61391 0 0))
This puzzled me a bit, but looking at the date, it's Wed Dec 31 23:59:59 GMT year (wait for it)
2147485547 = 1900 + 2**31-1
So it's again the usual issue, kicked up to higher timestamps in the 64-bit case:
http://www.unixguide.net/sun/faq/6.27.shtml
On October 29, 2019 10:06:28 AM EDT, "A.C." <achirvasub@gmail.com> wrote:
>
>
>On October 29, 2019 8:47:02 AM EDT, Lars Ingebrigtsen <larsi@gnus.org>
>wrote:
>>"A.C." <achirvasub@gmail.com> writes:
>>
>>> On the other hand, the Debian i686 system that doesn't load
>arxiv.org
>>has a
>>> largest valid n of
>>
>>I'm not quite sure I understood the bug report -- are you saying that
>>this is only an issue on 32-bit systems?
>>
>
>I don't have access to enough systems to tell for sure. I do know it's
>only happening on the one 32-bit system I have access to right now, and
>also that I hit the problem a while back on 32-bit ARM:
>
>https://github.com/termux/termux-packages/issues/2614
>
>(and have not see the issue on any 64-bit systems)
>
>>In any case, Emacs 27 has bignum support, so this should hopefully not
>>be a problem any more. Can you try the test case with the current
>>Emacs
>>trunk and see whether it's still present?
>
>That will be tough. This 32-bit machine overheats something fierce; I
>doubt I can even clone the git repo without it dying, let alone
>compile.
>
>--
>Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
[-- Attachment #2: Type: text/html, Size: 2555 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#37974: eww produces "error in process filter: Specified time is not representable"
2019-10-29 14:06 ` A.C.
2019-10-29 14:41 ` A.C.
@ 2019-10-29 21:52 ` Lars Ingebrigtsen
2019-10-29 22:23 ` A.C.
1 sibling, 1 reply; 16+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-29 21:52 UTC (permalink / raw
To: A.C.; +Cc: 37974
"A.C." <achirvasub@gmail.com> writes:
>>In any case, Emacs 27 has bignum support, so this should hopefully not
>>be a problem any more. Can you try the test case with the current
>>Emacs
>>trunk and see whether it's still present?
>
> That will be tough. This 32-bit machine overheats something fierce; I
> doubt I can even clone the git repo without it dying, let alone
> compile.
Testing a bit more, the bug is present even on 64-bits systems.
While this works:
(format-time-string "%a %b %d %H:%M:%S %Y GMT" 9460800000000000 t)
=> "Wed Apr 08 00:00:00 299802787 GMT"
(format-time-string "%a %b %d %H:%M:%S %Y GMT" 94608000000000000 t)
errors out with
"Specified time is not representable"
Test case:
(url-cookie-handle-set-cookie "browser=68.133.6.220.1572324160979722; path=/; max-age=946080000000000000; domain=.arxiv.org")
The input is completely controlled by the server, of course, and bogus
data may appear in the cookie, and the URL library should protect
against this, so I've now made it ignore these errors in Emacs 27. This
patch may also apply to the version of Emacs you're using; I haven't
checked.
diff --git a/lisp/url/url-cookie.el b/lisp/url/url-cookie.el
index 31fc3e7266..740a43fa16 100644
--- a/lisp/url/url-cookie.el
+++ b/lisp/url/url-cookie.el
@@ -304,9 +304,10 @@ url-cookie-handle-set-cookie
(url-filename url-current-object))))
(expires nil))
(if (and max-age (string-match "\\`-?[0-9]+\\'" max-age))
- (setq expires (format-time-string "%a %b %d %H:%M:%S %Y GMT"
- (time-add nil (read max-age))
- t))
+ (setq expires (ignore-errors
+ (format-time-string "%a %b %d %H:%M:%S %Y GMT"
+ (time-add nil (read max-age))
+ t)))
(setq expires (cdr-safe (assoc-string "expires" args t))))
(while (consp trusted)
(if (string-match (car trusted) current-url)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply related [flat|nested] 16+ messages in thread
* bug#37974: eww produces "error in process filter: Specified time is not representable"
2019-10-29 21:52 ` Lars Ingebrigtsen
@ 2019-10-29 22:23 ` A.C.
2019-10-30 10:19 ` Colin Baxter
0 siblings, 1 reply; 16+ messages in thread
From: A.C. @ 2019-10-29 22:23 UTC (permalink / raw
To: Lars Ingebrigtsen; +Cc: 37974
[-- Attachment #1: Type: text/plain, Size: 2685 bytes --]
On October 29, 2019 5:52:02 PM EDT, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>"A.C." <achirvasub@gmail.com> writes:
>
>>>In any case, Emacs 27 has bignum support, so this should hopefully
>not
>>>be a problem any more. Can you try the test case with the current
>>>Emacs
>>>trunk and see whether it's still present?
>>
>> That will be tough. This 32-bit machine overheats something fierce; I
>> doubt I can even clone the git repo without it dying, let alone
>> compile.
>
>Testing a bit more, the bug is present even on 64-bits systems.
>
>While this works:
>
>(format-time-string "%a %b %d %H:%M:%S %Y GMT" 9460800000000000 t)
>=> "Wed Apr 08 00:00:00 299802787 GMT"
>
>(format-time-string "%a %b %d %H:%M:%S %Y GMT" 94608000000000000 t)
>
>errors out with
>
>"Specified time is not representable"
Absolutely; I noted as much in the follow-up email to the one you cited above:
While 32-bit systems are vulnerable to the "year-2038 problem" 64-bit ones have an issue with year
2147485548 = 1900 + 2**31
So you can only go up to
Wed Dec 31 23:59:59 GMT 2147485547
meaning the highest it'll run without error is
(format-time-string "%a %b %d %H:%M:%S %Y GMT" 67768036191676799 t)
As soon as you try
67768036191676800 = 67768036191676799 + 1
you'll get the
"Specified time is not representable"
complaint.
>
>Test case:
>
>(url-cookie-handle-set-cookie "browser=68.133.6.220.1572324160979722;
>path=/; max-age=946080000000000000; domain=.arxiv.org")
>
>The input is completely controlled by the server, of course, and bogus
>data may appear in the cookie, and the URL library should protect
>against this, so I've now made it ignore these errors in Emacs 27.
>This
>patch may also apply to the version of Emacs you're using; I haven't
>checked.
>
>diff --git a/lisp/url/url-cookie.el b/lisp/url/url-cookie.el
>index 31fc3e7266..740a43fa16 100644
>--- a/lisp/url/url-cookie.el
>+++ b/lisp/url/url-cookie.el
>@@ -304,9 +304,10 @@ url-cookie-handle-set-cookie
> (url-filename url-current-object))))
> (expires nil))
> (if (and max-age (string-match "\\`-?[0-9]+\\'" max-age))
>- (setq expires (format-time-string "%a %b %d %H:%M:%S %Y GMT"
>- (time-add nil (read max-age))
>- t))
>+ (setq expires (ignore-errors
>+ (format-time-string "%a %b %d %H:%M:%S %Y GMT"
>+ (time-add nil (read max-age))
>+ t)))
> (setq expires (cdr-safe (assoc-string "expires" args t))))
> (while (consp trusted)
> (if (string-match (car trusted) current-url)
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
[-- Attachment #2: Type: text/html, Size: 3071 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#37974: eww produces "error in process filter: Specified time is not representable"
2019-10-29 22:23 ` A.C.
@ 2019-10-30 10:19 ` Colin Baxter
2019-10-30 11:01 ` Lars Ingebrigtsen
0 siblings, 1 reply; 16+ messages in thread
From: Colin Baxter @ 2019-10-30 10:19 UTC (permalink / raw
To: A.C.; +Cc: 37974, Lars Ingebrigtsen
[-- Attachment #1: Type: text/plain, Size: 768 bytes --]
>>>>> A C <achirvasub@gmail.com> writes:
> On October 29, 2019 5:52:02 PM EDT, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>> "A.C." <achirvasub@gmail.com> writes:
>>
>>>> In any case, Emacs 27 has bignum support, so this should
>>>> hopefully
>> not
>>>> be a problem any more. Can you try the test case with the
>>>> current Emacs trunk and see whether it's still present?
>>>
>>> That will be tough. This 32-bit machine overheats something
>>> fierce; I doubt I can even clone the git repo without it dying,
>>> let alone compile.
If it helps, I see no problem on the latest pull of emacs-27. I'm on
Linux 3.16.0-10-686-pae #1 SMP Debian 3.16.74-1 (2019-09-24) i686
GNU/Linux. Screen-shot below. Sorry to butt in.
[-- Attachment #2: screenshot --]
[-- Type: image/png, Size: 58586 bytes --]
[-- Attachment #3: Type: text/plain, Size: 53 bytes --]
Best wishes,
--
Colin Baxter
www.Colin-Baxter.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#37974: eww produces "error in process filter: Specified time is not representable"
2019-10-30 10:19 ` Colin Baxter
@ 2019-10-30 11:01 ` Lars Ingebrigtsen
2019-10-31 18:50 ` A.C.
0 siblings, 1 reply; 16+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-30 11:01 UTC (permalink / raw
To: Colin Baxter; +Cc: 37974, A.C.
Colin Baxter <m43cap@yandex.com> writes:
> If it helps, I see no problem on the latest pull of emacs-27. I'm on
> Linux 3.16.0-10-686-pae #1 SMP Debian 3.16.74-1 (2019-09-24) i686
> GNU/Linux. Screen-shot below.
Yeah, if you have the latest pull, then you have my fix for this
problem.
> Sorry to butt in.
Butting in is what the bug tracker is for. :-)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#37974: eww produces "error in process filter: Specified time is not representable"
2019-10-30 11:01 ` Lars Ingebrigtsen
@ 2019-10-31 18:50 ` A.C.
2019-11-01 13:46 ` Lars Ingebrigtsen
0 siblings, 1 reply; 16+ messages in thread
From: A.C. @ 2019-10-31 18:50 UTC (permalink / raw
To: Lars Ingebrigtsen, Colin Baxter; +Cc: 37974
[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]
But this resolves the 32-bit issue only, correct?
I did end up compiling the latest version (27.0.50, as reported by 'emacs --version') cloned from
git://git.savannah.gnu.org/emacs.git
on a 64-bit system and
(format-time-string "%a %b %d %H:%M:%S %Y GMT" 67768036191676800 t)
still chokes with the "Specified time is not representable" error. As before, the same expression evaluates fine to
"Wed Dec 31 23:59:59 2147485547 GMT"
with the smaller number
67768036191676799 = 67768036191676800 - 1
On October 30, 2019 7:01:21 AM EDT, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>Colin Baxter <m43cap@yandex.com> writes:
>
>> If it helps, I see no problem on the latest pull of emacs-27. I'm on
>> Linux 3.16.0-10-686-pae #1 SMP Debian 3.16.74-1 (2019-09-24) i686
>> GNU/Linux. Screen-shot below.
>
>Yeah, if you have the latest pull, then you have my fix for this
>problem.
>
>> Sorry to butt in.
>
>Butting in is what the bug tracker is for. :-)
>
>--
>(domestic pets only, the antidote for overdose, milk.)
> bloggy blog: http://lars.ingebrigtsen.no
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
[-- Attachment #2: Type: text/html, Size: 1632 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#37974: eww produces "error in process filter: Specified time is not representable"
2019-10-29 0:32 bug#37974: eww produces "error in process filter: Specified time is not representable" Stuart Little
2019-10-29 4:51 ` Stuart Little
@ 2019-11-01 8:05 ` Paul Eggert
2019-11-01 23:22 ` Paul Eggert
1 sibling, 1 reply; 16+ messages in thread
From: Paul Eggert @ 2019-11-01 8:05 UTC (permalink / raw
To: A.C.; +Cc: 37974
> But this resolves the 32-bit issue only, correct?
Lars's patch should fix the eww problem on both 32- and 64-bit platforms.
> (format-time-string "%a %b %d %H:%M:%S %Y GMT" 67768036191676800 t)
>
> still chokes with the "Specified time is not representable" error.
That's due to operating system limits, and is not eww's fault per se. Typical
operating systems are limited to timestamps that fit into 64-bit signed
integers, or into 32-bit unsigned or signed integers.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#37974: eww produces "error in process filter: Specified time is not representable"
2019-10-31 18:50 ` A.C.
@ 2019-11-01 13:46 ` Lars Ingebrigtsen
0 siblings, 0 replies; 16+ messages in thread
From: Lars Ingebrigtsen @ 2019-11-01 13:46 UTC (permalink / raw
To: A.C.; +Cc: Colin Baxter, 37974
"A.C." <achirvasub@gmail.com> writes:
> But this resolves the 32-bit issue only, correct?
It resolves the eww/cookie problem on all architectures, but it doesn't
enable Emacs to format all dates. That's done by strftime, so it's up
to the OS how many bits are supported.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#37974: eww produces "error in process filter: Specified time is not representable"
2019-11-01 8:05 ` Paul Eggert
@ 2019-11-01 23:22 ` Paul Eggert
2019-11-02 7:34 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Paul Eggert @ 2019-11-01 23:22 UTC (permalink / raw
To: A.C.; +Cc: 37974
[-- Attachment #1: Type: text/plain, Size: 273 bytes --]
On 11/1/19 1:05 AM, Paul Eggert wrote:
> That's due to operating system limits, and is not eww's fault per se.
That being said, this bug report suggests that the issue of OS limits on
timestamps should be documented better. I installed the attached to try
to do that.
[-- Attachment #2: 0001-Document-limits-on-some-time-conversion-functions.patch --]
[-- Type: text/x-patch, Size: 5591 bytes --]
From feb7e22ed4598baacf08378f2208caba0d214e97 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Fri, 1 Nov 2019 16:13:31 -0700
Subject: [PATCH] Document limits on some time-conversion functions
* doc/lispref/os.texi (Time of Day, Time Zone Rules)
(Time Conversion, Time Parsing, Time Calculations):
Document functions that limit the range of time values
due to OS limits (Bug#37974).
---
doc/lispref/os.texi | 32 ++++++++++++++++++++++----------
1 file changed, 22 insertions(+), 10 deletions(-)
diff --git a/doc/lispref/os.texi b/doc/lispref/os.texi
index d8d0ad7206..d3ddee251b 100644
--- a/doc/lispref/os.texi
+++ b/doc/lispref/os.texi
@@ -1307,7 +1307,14 @@ Time of Day
time, a single floating-point number for seconds, or a list
@code{(@var{high} @var{low} @var{micro})} or @code{(@var{high}
@var{low})} that is a truncated list timestamp with missing elements
-taken to be zero. You can convert a time value into
+taken to be zero.
+
+Time values can be converted to and from calendrical and other forms.
+Some of these conversions rely on operating system functions that
+limit the range of possible time values, and signal an error if the
+limits are exceeded. For instance, a system may not support years
+before 1970, or years before 1901, or years far in the future.
+You can convert a time value into
a human-readable string using @code{format-time-string}, into a Lisp
timestamp using @code{time-convert}, and into other forms using
@code{decode-time} and @code{float-time}. These functions are
@@ -1328,11 +1335,12 @@ Time of Day
The argument @var{time}, if given, specifies a time to format,
instead of the current time. The optional argument @var{zone}
defaults to the current time zone rule. @xref{Time Zone Rules}.
+The operating system limits the range of time and zone values.
@example
@group
(current-time-string)
- @result{} "Wed Oct 14 22:21:05 1987"
+ @result{} "Fri Nov @ 1 15:59:49 2019"
@end group
@end example
@end defun
@@ -1416,6 +1424,7 @@ Time Zone Rules
The argument @var{time}, if given, specifies a time value to
analyze instead of the current time. The optional argument @var{zone}
defaults to the current time zone rule.
+The operating system limits the range of time and zone values.
@end defun
@node Time Conversion
@@ -1498,6 +1507,8 @@ Time Conversion
This function converts a time value into calendrical information. If
you don't specify @var{time}, it decodes the current time, and similarly
@var{zone} defaults to the current time zone rule. @xref{Time Zone Rules}.
+The operating system limits the range of time and zone values.
+
The @var{form} argument controls the form of the returned
@var{seconds} element, as described below.
The return value is a list of nine elements, as follows:
@@ -1631,6 +1642,7 @@ Time Conversion
Year numbers less than 100 are not treated specially. If you want them
to stand for years above 1900, or years above 2000, you must alter them
yourself before you call @code{encode-time}.
+The operating system limits the range of time values.
The @code{encode-time} function acts as a rough inverse to
@code{decode-time}. For example, you can pass the output of
@@ -1643,11 +1655,6 @@ Time Conversion
You can perform simple date arithmetic by using out-of-range values for
@var{seconds}, @var{minutes}, @var{hour}, @var{day}, and @var{month};
for example, day 0 means the day preceding the given month.
-
-The operating system puts limits on the range of possible time values;
-if the limits are exceeded while encoding the time, an error results.
-For instance, years before 1970 do not work on some systems;
-on others, years as early as 1901 do work.
@end defun
@node Time Parsing
@@ -1666,6 +1673,7 @@ Time Parsing
a date-time, and should be in one of the forms recognized by
@code{parse-time-string} (see below). This function assumes the GMT
timezone if @var{string} lacks an explicit timezone information.
+The operating system limits the range of time values.
@end defun
@defun parse-time-string string
@@ -1847,10 +1855,12 @@ Time Parsing
This function uses the C library function @code{strftime}
(@pxref{Formatting Calendar Time,,, libc, The GNU C Library Reference
Manual}) to do most of the work. In order to communicate with that
-function, it first encodes its argument using the coding system
+function, it first converts @var{time} and @var{zone} to internal form;
+the operating system limits the range of time and zone values.
+This function also encodes @var{format-string} using the coding system
specified by @code{locale-coding-system} (@pxref{Locales}); after
@code{strftime} returns the resulting string,
-@code{format-time-string} decodes the string using that same coding
+this function decodes the string using that same coding
system.
@end defun
@@ -1990,10 +2000,12 @@ Time Calculations
@defun time-to-days time-value
This function returns the number of days between the beginning of year
1 and @var{time-value}.
+The operating system limits the range of time values.
@end defun
@defun time-to-day-in-year time-value
This returns the day number within the year corresponding to @var{time-value}.
+The operating system limits the range of time values.
@end defun
@defun date-leap-year-p year
@@ -2002,7 +2014,7 @@ Time Calculations
@defun date-days-in-month year month
Return the number of days in @var{month} in @var{year}. For instance,
-there's 29 days in February 2004.
+February 2020 has 29 days.
@end defun
@defun date-ordinal-to-time year ordinal
--
2.23.0
^ permalink raw reply related [flat|nested] 16+ messages in thread
* bug#37974: eww produces "error in process filter: Specified time is not representable"
2019-11-01 23:22 ` Paul Eggert
@ 2019-11-02 7:34 ` Eli Zaretskii
0 siblings, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2019-11-02 7:34 UTC (permalink / raw
To: Paul Eggert; +Cc: 37974, achirvasub
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 1 Nov 2019 16:22:58 -0700
> Cc: 37974@debbugs.gnu.org
>
> > That's due to operating system limits, and is not eww's fault per se.
>
> That being said, this bug report suggests that the issue of OS limits on
> timestamps should be documented better. I installed the attached to try
> to do that.
Thanks.
Can you think about useful index entries for this information? What
topic would a user who bumps into these problems have in mind to look
up in the manual?
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2019-11-02 7:34 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-10-29 0:32 bug#37974: eww produces "error in process filter: Specified time is not representable" Stuart Little
2019-10-29 4:51 ` Stuart Little
2019-10-29 10:25 ` Stuart Little
2019-10-29 12:05 ` A.C.
2019-10-29 12:47 ` Lars Ingebrigtsen
2019-10-29 14:06 ` A.C.
2019-10-29 14:41 ` A.C.
2019-10-29 21:52 ` Lars Ingebrigtsen
2019-10-29 22:23 ` A.C.
2019-10-30 10:19 ` Colin Baxter
2019-10-30 11:01 ` Lars Ingebrigtsen
2019-10-31 18:50 ` A.C.
2019-11-01 13:46 ` Lars Ingebrigtsen
2019-11-01 8:05 ` Paul Eggert
2019-11-01 23:22 ` Paul Eggert
2019-11-02 7:34 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.