GNU bug report logs - #44566
27.1; time bug at Gnus

Previous Next

Full log

Message #67 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Peder O. Klingenberg" <peder <at> news.klingenberg.no>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#44566: 27.1; time bug at Gnus
Date: Wed, 11 Nov 2020 14:25:57 +0100

On on., 2020-11-11 kl. 12.51 +0100 +0100, Andreas Schwab wrote:

> On Nov 11 2020, Peder O. Klingenberg wrote:
>
>> Second, the NNTP edition of the same message, with a date header like
>> this:
>>
>> Date: Wed, 11 Nov 2020 03:18:55 CET (8 hours, 22 minutes, 37 seconds ago)
>>
>> The second timestamp is transposed to CET, but describes the same point
>> in time as the first.
>
> No, it describes the date 2020-11-11 03:18:55 +0000.  It lacks a time
> zone, thus UTC0 is assumed.

"Be conservative in what you send, be liberal in what you accept."  The
date string comes from an NNTP server.  The format is close to, but not
necessarily identical to, that described by the email RFC you pointed to
in another message.  I seem to remember, but can't be bothered to look
up, that NNTP was never really standardized to the same degree as email,
and thus Postels Law surely applies.

To my human eyes, it's obvious that CET == +0100.  (and CEST == +0200)
I'm in favor of teaching gnus the same interpretation, rather than
insisting on fixing random NNTP servers.  I'm guessing most NNTP servers
don't see much new development these days.

Besides, there's still a bug if we accept that the date should be read
as UTC0, as you say. +0000 vs +0100 should account for just one hour
difference in the article-lapsed-time, not eight.  (03:18:55 +0000 is
12:18:55 +0900, and the article-lapsed-time should have been something
like "37 minutes, 23 seconds in the future", if I've counted in the
right direction.)

...Peder...
-- 
Sløv uten dop

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.