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

Previous Next

Full log

View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Peder O. Klingenberg" <peder <at> news.klingenberg.no>
Cc: 44566 <at> debbugs.gnu.org
Subject: bug#44566: 27.1; time bug at Gnus
Date: Thu, 12 Nov 2020 13:11:41 +0100

"Peder O. Klingenberg" <peder <at> news.klingenberg.no> writes:

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

The "CET" thing is a local customisation -- most NNTP servers use
standardised (i.e., numerical) time zones.

I'm not necessarily against having parse-time-string guess at what
symbolic time zones are supposed to represent, but where do we stop?
CET, sure, but then what about BST (Bangladesh Standard Time and
Bougainville Standard Time)?

parse-time-string not having supported this for, well, ever, and
somebody complaining about it in 2020 is perhaps an indicator that there
are few misconfigured NNTP servers out there 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.)

I don't think the CET is interpreted as UTC0 -- it's interpreted as
local time?  And Byung-Hee is in +09:00, which is eight hours from
+01:00.

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

Previous Next

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