bug#37974: eww produces "error in process filter: Specified time is not representable"

bug#37974: eww produces "error in process filter: Specified time is not representable"

[Stuart Little]

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.

bug#37974: eww produces "error in process filter: Specified time is not representable"

[Stuart Little]

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.

bug#37974: eww produces "error in process filter: Specified time is not representable"

[Stuart Little]

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.

bug#37974: eww produces "error in process filter: Specified time is not representable"

[A.C.]

[-- 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 --]

bug#37974: eww produces "error in process filter: Specified time is not representable"

[Lars Ingebrigtsen]

"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

bug#37974: eww produces "error in process filter: Specified time is not representable"

[A.C.]

[-- 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 --]

bug#37974: eww produces "error in process filter: Specified time is not representable"

[A.C.]

[-- 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 --]

bug#37974: eww produces "error in process filter: Specified time is not representable"

[Lars Ingebrigtsen]

"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

bug#37974: eww produces "error in process filter: Specified time is not representable"

[A.C.]

[-- 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 --]

bug#37974: eww produces "error in process filter: Specified time is not representable"

[Colin Baxter]

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

bug#37974: eww produces "error in process filter: Specified time is not representable"

[Lars Ingebrigtsen]

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

bug#37974: eww produces "error in process filter: Specified time is not representable"

[A.C.]

[-- 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 --]

bug#37974: eww produces "error in process filter: Specified time is not representable"

[Lars Ingebrigtsen]

"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

bug#37974: eww produces "error in process filter: Specified time is not representable"

[Paul Eggert]

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

bug#37974: eww produces "error in process filter: Specified time is not representable"

[Paul Eggert]

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

bug#37974: eww produces "error in process filter: Specified time is not representable"

[Eli Zaretskii]

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