bug#44566: 27.1; time bug at Gnus

bug#44566: 27.1; time bug at Gnus

[황병희]

Hellow, i sent mail to usenet. then i checked the mails. at sent folder
and usenet server. i did attach the two screenshot. there is lack about
8 hours. i think that is bug on time calculating in Gnus. how think
about?

Screenshots URL:
===> https://gitlab.com/soyeomul/Gnus/-/commit/a84a5eed2b36c71d3c057689fc28fb75184d3ad6

Sincerely, Gnus fan Byung-Hee

In GNU Emacs 27.1 (build 1, aarch64-unknown-linux-gnu, GTK+ Version 3.22.30, cairo version 1.15.10)
 of 2020-09-20 built on bos02-arm64-036
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Ubuntu 18.04.5 LTS

Recent messages:
Checking new news...done
Opening nntp server on news.gmane.io...done
Beginning of buffer [4 times]
End of buffer
Beginning of buffer [32 times]
Opening nntp server on koldfront...done
Auto-saving...done
Beginning of buffer [29 times]
No more unseen articles
Auto-saving...

Configured using:
 'configure --build=aarch64-linux-gnu --prefix=/usr
 '--includedir=${prefix}/include' '--mandir=${prefix}/share/man'
 '--infodir=${prefix}/share/info' --sysconfdir=/etc --localstatedir=/var
 --disable-silent-rules '--libdir=${prefix}/lib/aarch64-linux-gnu'
 '--libexecdir=${prefix}/lib/aarch64-linux-gnu'
 --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/27.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/27.1/site-lisp:/usr/share/emacs/site-lisp
 --program-suffix=27 --with-modules --with-file-notification=inotify
 --with-mailutils --with-harfbuzz --with-json --with-x=yes
 --with-x-toolkit=gtk3 --with-lcms2 --with-cairo --with-xpm=yes
 --with-gif=yes --with-gnutls=yes --with-jpeg=yes --with-png=yes
 --with-tiff=yes --with-xwidgets 'CFLAGS=-g -O2
 -fdebug-prefix-map=/build/emacs27-3YOx4z/emacs27-27.1~1.git86d8d76aa3=. -fstack-protector-strong
 -Wformat -Werror=format-security' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS
LIBSYSTEMD JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LC_MESSAGES: POSIX
  value of $LANG: ko_KR.UTF-8
  value of $XMODIFIERS: @im=nabi
  locale-coding-system: utf-8-unix

Major mode: Summary

Minor modes in effect:
  erc-list-mode: t
  erc-menu-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-networks-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-track-minor-mode: t
  erc-match-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-netsplit-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
/usr/share/emacs/site-lisp/dictionaries-common/flyspell hides /usr/share/emacs/27.1/lisp/textmodes/flyspell
/usr/share/emacs/site-lisp/dictionaries-common/ispell hides /usr/share/emacs/27.1/lisp/textmodes/ispell

Features:
(shadow emacsbug mule-util mm-archive sendmail nnir url-http url-gw
url-auth gnus-gravatar gravatar url-cache gnus-picon sort gnus-fun
smiley gnus-cite mail-extr gnus-async gnus-bcklg qp gnus-ml
cursor-sensor nndraft nnmh nndoc utf-7 nnfolder cl-extra gnutls
network-stream nsm gnus-agent gnus-srvr gnus-score score-mode nnvirtual
gnus-msg nntp gnus-cache gnus-registry registry eieio-base gnus-art
mm-uu mml2015 mm-view mml-smime smime dig gnus-sum url url-proxy
url-privacy url-expand url-methods url-history mailcap shr url-cookie
url-domsuf url-util url-parse url-vars svg xml dom gnus-group gnus-undo
gnus-start gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo
parse-time iso8601 gnus-spec gnus-int gnus-range message rmc puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg epg-config mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
gnus-win gnus nnheader gnus-util rmail rmail-loaddefs rfc2047 rfc2045
ietf-drums text-property-search mail-utils mm-util mail-prsvr erc-list
erc-menu erc-join erc-ring erc-networks erc-pcomplete time-date
erc-track erc-match erc-button browse-url wid-edit erc-fill erc-stamp
erc-netsplit erc-goodies erc erc-backend erc-compat format-spec
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map seq byte-opt gv bytecomp byte-compile
cconv thingatpt pp erc-loaddefs em-unix em-term term disp-table ehelp
em-script em-prompt em-ls em-hist em-pred em-glob em-dirs esh-var
em-cmpl pcomplete comint ansi-color ring em-basic em-banner em-alias
esh-mode eshell esh-cmd esh-ext esh-opt esh-proc esh-io esh-arg
esh-module esh-groups esh-util edmacro kmacro hangul hanja-util quail
help-mode easymenu cl-loaddefs cl-lib korea-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting xwidget-internal cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 373176 24785)
 (symbols 48 20407 2)
 (strings 32 94614 6353)
 (string-bytes 1 3235320)
 (vectors 16 38786)
 (vector-slots 8 1437845 96174)
 (floats 8 260 328)
 (intervals 56 2754 72)
 (buffers 1000 49))

-- 
^고맙습니다 _和合團結_ 감사합니다_^))//

bug#44566: 27.1; time bug at Gnus

[황병희]

And i attach the ~/.gnus file.
===>
https://gitlab.com/soyeomul/Gnus/-/raw/c1d12748f615f754c2ed27bc1d5c63a3d3e2a4c1/dot.gnus.el

Sincerely, Gnus fan Byung-Hee

-- 
^고맙습니다 _和合團結_ 감사합니다_^))//

bug#44566: 27.1; time bug at Gnus

[황병희]

X-Debbugs-CC: asjo@koldfront.dk

After hard try, i found related chagelog in Emacs 27.1 branch.

#+BEGIN_SRC text
2019-07-20  Adam Sjøgren  <asjo@koldfront.dk>

        Enable showing local time and lapsed time in Gnus

        * lisp/gnus/gnus-art.el (article-make-date-combine-with-lapsed) factor
        code out into new function, used for providing both combined-lapsed
        and combined-local-lapsed.
#+END_SRC

But still i don't know what problem is in detail...

Sincerely, Gnus fan Byung-Hee

-- 
^고맙습니다 _和合團結_ 감사합니다_^))//

bug#44566: 27.1; time bug at Gnus

[Unknown]

What brings you to the conclusion that this is a bug in Gnus?

bug#44566: 27.1; time bug at Gnus

[Lars Ingebrigtsen]

황병희 <soyeomul@doraji.xyz> writes:

> Hellow, i sent mail to usenet. then i checked the mails. at sent folder
> and usenet server. i did attach the two screenshot. there is lack about
> 8 hours. i think that is bug on time calculating in Gnus. how think
> about?

I'm not quite sure what you're asking here.  The screenshots showed that
you were posting first using the +0900 time zone, and then you were
posting using the CET time zone, and the difference between these time
zones are, as you point out, eight hours.

So you've changed time zones?  

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

bug#44566: 27.1; time bug at Gnus

[황병희]

Unknown <unknown@unknown.invalid> writes:

> What brings you to the conclusion that this is a bug in Gnus?

lapsed time. that two screenshot is very different.

Sincerely, Byung-Hee

-- 
^고맙습니다 _和合團結_ 감사합니다_^))//

bug#44566: 27.1; time bug at Gnus

[황병희]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> 황병희 <soyeomul@doraji.xyz> writes:
>
>> Hellow, i sent mail to usenet. then i checked the mails. at sent folder
>> and usenet server. i did attach the two screenshot. there is lack about
>> 8 hours. i think that is bug on time calculating in Gnus. how think
>> about?
>
> I'm not quite sure what you're asking here.  The screenshots showed that
> you were posting first using the +0900 time zone, and then you were
> posting using the CET time zone, and the difference between these time
> zones are, as you point out, eight hours.

I think "lapsed time" should be same regardless of timezone.

Sincerely, Byung-Hee

-- 
^고맙습니다 _和合團結_ 감사합니다_^))//

bug#44566: 27.1; time bug at Gnus

[Lars Ingebrigtsen]

황병희 <soyeomul@doraji.xyz> writes:

> I think "lapsed time" should be same regardless of timezone.

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?

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

bug#44566: 27.1; time bug at Gnus

[황병희]

[Cc'ed Adam]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> 황병희 <soyeomul@doraji.xyz> writes:
>
>> I think "lapsed time" should be same regardless of timezone.
>
> 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?

That was my fault without background my thought. Sorry about that, Lars.

And i do re-submit exact and detail screenshot:
===>
https://gitlab.com/soyeomul/Gnus/-/commit/487f47cdc9fe999eb5a7683a3eb3bbffc0156203

Both have same Message-ID. But both "lapsed time" are very different. I
think "lapsed time" should be same(at least similar) in logical.

Sincerely, Byung-Hee

-- 
^고맙습니다 _和合團結_ 감사합니다_^))//

bug#44566: 27.1; time bug at Gnus

[Peder O. Klingenberg]

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.


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

bug#44566: 27.1; time bug at Gnus

[Lars Ingebrigtsen]

황병희 <soyeomul@doraji.xyz> writes:

> That was my fault without background my thought. Sorry about that, Lars.
>
> And i do re-submit exact and detail screenshot:
> ===>
> https://gitlab.com/soyeomul/Gnus/-/commit/487f47cdc9fe999eb5a7683a3eb3bbffc0156203
>
> Both have same Message-ID. But both "lapsed time" are very different. I
> think "lapsed time" should be same(at least similar) in logical.

I still don't understand.  Is that the screenshot of the same message
from two different Gnus sessions?  If so, what's the first Gnus version,
and what's the second?

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

bug#44566: 27.1; time bug at Gnus

[Andreas Schwab]

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.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

bug#44566: 27.1; time bug at Gnus

[황병희]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> 황병희 <soyeomul@doraji.xyz> writes:
>
>> That was my fault without background my thought. Sorry about that, Lars.
>>
>> And i do re-submit exact and detail screenshot:
>> ===>
>> https://gitlab.com/soyeomul/Gnus/-/commit/487f47cdc9fe999eb5a7683a3eb3bbffc0156203
>>
>> Both have same Message-ID. But both "lapsed time" are very different. I
>> think "lapsed time" should be same(at least similar) in logical.
>
> I still don't understand.  Is that the screenshot of the same message
> from two different Gnus sessions?  If so, what's the first Gnus version,
> and what's the second?

The screenshot's two Gnus are same version.
I did launch two Emacs for take screenshot. 

Sincerely, Gnus fan Byung-Hee

-- 
^고맙습니다 _和合團結_ 감사합니다_^))//

bug#44566: 27.1; time bug at Gnus

[Lars Ingebrigtsen]

(parse-time-string "Wed, 11 Nov 2020 03:18:55 CET")
=> (55 18 3 11 11 2020 3 -1 nil)

(parse-time-string "Wed, 11 Nov 2020 11:18:55 +0900")
=> (55 18 11 11 11 2020 3 -1 32400)

Hm!  So `parse-time-string' doesn't understand symbolic (and ambiguous)
time zones?  Should it?

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

bug#44566: 27.1; time bug at Gnus

[Lars Ingebrigtsen]

Heh.  It has coverage for this somewhat eccentric range of (legacy) time
zone names:

(defvar parse-time-zoneinfo `(("z" 0) ("ut" 0) ("gmt" 0)
			      ("pst" ,(* -8 3600)) ("pdt" ,(* -7 3600) t)
			      ("mst" ,(* -7 3600)) ("mdt" ,(* -6 3600) t)
			      ("cst" ,(* -6 3600)) ("cdt" ,(* -5 3600) t)
			      ("est" ,(* -5 3600)) ("edt" ,(* -4 3600) t))
  "(zoneinfo seconds-off daylight-savings-time-p)")


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

bug#44566: 27.1; time bug at Gnus

[황병희]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Heh.  It has coverage for this somewhat eccentric range of (legacy) time
> zone names:
>
> (defvar parse-time-zoneinfo `(("z" 0) ("ut" 0) ("gmt" 0)
> 			      ("pst" ,(* -8 3600)) ("pdt" ,(* -7 3600) t)
> 			      ("mst" ,(* -7 3600)) ("mdt" ,(* -6 3600) t)
> 			      ("cst" ,(* -6 3600)) ("cdt" ,(* -5 3600) t)
> 			      ("est" ,(* -5 3600)) ("edt" ,(* -4 3600) t))
>   "(zoneinfo seconds-off daylight-savings-time-p)")

Thank You Very Much!!! 

Sincerely, Gnus fan Byung-Hee

-- 
^고맙습니다 _和合團結_ 감사합니다_^))//

bug#44566: 27.1; time bug at Gnus

[황병희]

Dear Peder,

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

Thank you for good explain!!!

Sincerely, Byung-Hee

-- 
^고맙습니다 _和合團結_ 감사합니다_^))//

bug#44566: 27.1; time bug at Gnus

[Andreas Schwab]

On Nov 11 2020, Lars Ingebrigtsen wrote:

> Heh.  It has coverage for this somewhat eccentric range of (legacy) time
> zone names:
>
> (defvar parse-time-zoneinfo `(("z" 0) ("ut" 0) ("gmt" 0)
> 			      ("pst" ,(* -8 3600)) ("pdt" ,(* -7 3600) t)
> 			      ("mst" ,(* -7 3600)) ("mdt" ,(* -6 3600) t)
> 			      ("cst" ,(* -6 3600)) ("cdt" ,(* -5 3600) t)
> 			      ("est" ,(* -5 3600)) ("edt" ,(* -4 3600) t))
>   "(zoneinfo seconds-off daylight-savings-time-p)")

See obs-zone in RFC2822.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#44566: 27.1; time bug at Gnus

[Unknown]

I guess the first screenshot is of an archived outgoing article, and the
second screenshot is of the same article retrieved by nntp.

I am questioning that Gnus is doing something wrong here, because the
nntp-server in question is one I have implemented, and I think it's more
likely that my nntp-server doesn't handle timezones/follow the spec
correctly than Gnus being at fault.

bug#44566: 27.1; time bug at Gnus

[Peder O. Klingenberg]

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

bug#44566: 27.1; time bug at Gnus

[Unknown]

Adam writes:

> the nntp-server in question is one I have implemented, and I think
> it's more likely that my nntp-server doesn't handle timezones/follow
> the spec correctly than Gnus being at fault.

Specifically my code is using Data.Time.Format¹s defaultTimeLocale and
rfc822DateFormat, which doesn't seem to use the restricted list of
timezones defined in rfc(2)822:

  $ ghci
  GHCi, version 8.8.4: https://www.haskell.org/ghc/  :? for help
  Prelude> import Data.Time.LocalTime
  Prelude Data.Time.LocalTime> import Data.Time.Format
  Prelude Data.Time.LocalTime Data.Time.Format> now <- getZonedTime
  Prelude Data.Time.LocalTime Data.Time.Format> formatTime defaultTimeLocale rfc822DateFormat now
  "Wed, 11 Nov 2020 14:23:39 CET"

Despite the documentation saying:

   defaultTimeLocale :: TimeLocale

     Locale representing American usage.

     knownTimeZones contains only the ten time-zones mentioned in RFC 802
     sec. 5: "UT", "GMT", "EST", "EDT", "CST", "CDT", "MST", "MDT", "PST",
     "PDT". Note that the parsing functions will regardless parse "UTC",
     single-letter military time-zones, and +HHMM format.


¹ https://hackage.haskell.org/package/time-1.9.3/docs/Data-Time-Format.html#g:3

bug#44566: 27.1; time bug at Gnus

[Unknown]

I have changed the nntp-server in question to always output dates in GMT
- so instead of:

  Date: Wed, 11 Nov 2020 03:18:55 CET

for the article in question, it now outputs:

  Date: Wed, 11 Nov 2020 02:18:55 GMT

which should be correct according to rfc2822, I think, and allow Gnus to
show the correct lapsed time.

Sorry for the noise.

bug#44566: 27.1; time bug at Gnus

[황병희]

Unknown <unknown@unknown.invalid> writes:

> I have changed the nntp-server in question to always output dates in GMT
> - so instead of:
>
>   Date: Wed, 11 Nov 2020 03:18:55 CET
>
> for the article in question, it now outputs:
>
>   Date: Wed, 11 Nov 2020 02:18:55 GMT
>
> which should be correct according to rfc2822, I think, and allow Gnus to
> show the correct lapsed time.

Just now i did check that "lapsed time" with GMT (Adam's NNTP
server). Now all is good^^^ Thank you Adam^^^

Sincerely, Gnus fan Byung-Hee

-- 
^고맙습니다 _和合團結_ 감사합니다_^))//

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

bug#44566: 27.1; time bug at Gnus

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

>> (defvar parse-time-zoneinfo `(("z" 0) ("ut" 0) ("gmt" 0)
>> 			      ("pst" ,(* -8 3600)) ("pdt" ,(* -7 3600) t)
>> 			      ("mst" ,(* -7 3600)) ("mdt" ,(* -6 3600) t)
>> 			      ("cst" ,(* -6 3600)) ("cdt" ,(* -5 3600) t)
>> 			      ("est" ,(* -5 3600)) ("edt" ,(* -4 3600) t))
>>   "(zoneinfo seconds-off daylight-savings-time-p)")
>
> See obs-zone in RFC2822.

Ah; thanks.

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

bug#44566: 27.1; time bug at Gnus

[Lars Ingebrigtsen]

I think the conclusion here was that this was a configuration problem in
the NNTP server.

It might make sense for Emacs to make a guess at what the (non-standard)
time zones mean in `parse-time-string', but that's a whole can of worms,
so I'd rather now, and I'm closing this bug report.

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