bug#44566: 27.1; time bug at Gnus

[Lars Ingebrigtsen]

"Peder O. Klingenberg" <peder@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