bug#44566: 27.1; time bug at Gnus

[Lars Ingebrigtsen]

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

> On on., 2020-11-11 kl. 12.14 +0100 +0100, Lars Ingebrigtsen wrote:
>
>> Perhaps it'd be better if you described precisely what you think the
>> problem is (by giving us example Date headers) instead of posting
>> screenshots and asking us to guess what you think the problem is?
>
> Seems obvious to me.  Two screenshots, taken 30-ish seconds apart.  In
> the first, an archive copy of a message, with a Date header like so:
>
> Date: Wed, 11 Nov 2020 11:18:55 +0900 (22 minutes, 6 seconds ago)
>
> 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.  The thing between the parenthesis, calculated by
> gnus, should therefore obviously be the same, modulo the seconds between
> the screenshots.  It's not.  The difference is the same as the
> difference between time zones +0900 and CET, so it's not unlikely that
> somewhere Gnus drops the TZ information.

Thanks for the explanation.

`article-make-date-line' basically calls date-to-time on the header and
then formats the "lapsed" bit:

(date-to-time "Wed, 11 Nov 2020 03:18:55 CET")
=> (24491 18959)

(date-to-time "Wed, 11 Nov 2020 11:18:55 +0900")
=> (24491 18959)

which is in the local time zone.  It then calls

(article-lapsed-string '(24491 18959) 3)
=> "9 hours, 36 minutes, 55 seconds ago"

Byung-Hee, do you get something differing results if you eval (with `C-x
C-e', for instance) the forms above?

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