* bug#60325: 30.0.50; [PATCH] Fix rfc822 date decode in newsticker
@ 2022-12-25 23:32 LdBeth
2022-12-29 9:06 ` Eli Zaretskii
0 siblings, 1 reply; 5+ messages in thread
From: LdBeth @ 2022-12-25 23:32 UTC (permalink / raw)
To: 60325
[-- Attachment #1: Type: text/plain, Size: 200 bytes --]
Hi,
`newsticker--decode-rfc822-date' matches North American timezone in
regex, but the actually time stamp conversion was not implemented.
This patch fixes the missing timezone conversion.
---
ldb
[-- Attachment #2: 0001-Fix-newsticker-timezone-decode.patch --]
[-- Type: text/plain, Size: 2573 bytes --]
From c06782604df686dd17e6eab5caf64e1717f519dc Mon Sep 17 00:00:00 2001
From: LdBeth <andpuke@foxmail.com>
Date: Sun, 25 Dec 2022 17:15:12 -0600
Subject: [PATCH] Fix newsticker timezone decode
`newsticker--decode-rfc822-date' has the regex pattern for
North American timezones but the actual timezone conversion
for them was not implmented. Now cond cases are added to
handle them as specified in RFC822.
---
lisp/net/newst-backend.el | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/lisp/net/newst-backend.el b/lisp/net/newst-backend.el
index af196cc..2a87742 100644
--- a/lisp/net/newst-backend.el
+++ b/lisp/net/newst-backend.el
@@ -1623,7 +1623,7 @@ Sat, 07 Sep 2002 00:00:01 GMT
":\\([0-9]\\{2\\}\\)"
;; second
"\\(:\\([0-9]\\{2\\}\\)\\)?"
- ;; zone -- fixme
+ ;; zone
"\\(\\s-+\\("
"UT\\|GMT\\|EST\\|EDT\\|CST\\|CDT\\|MST\\|MDT\\|PST\\|PDT"
"\\|\\([-+]\\)\\([0-9]\\{2\\}\\)\\([0-9]\\{2\\}\\)"
@@ -1642,16 +1642,26 @@ Sat, 07 Sep 2002 00:00:01 GMT
(offset-hour (read (or (match-string 14 rfc822-string)
"0")))
(offset-minute (read (or (match-string 15 rfc822-string)
- "0")))
- ;;FIXME
- )
+ "0"))))
(when zone
(cond ((string= sign "+")
(setq hour (- hour offset-hour))
(setq minute (- minute offset-minute)))
((string= sign "-")
(setq hour (+ hour offset-hour))
- (setq minute (+ minute offset-minute)))))
+ (setq minute (+ minute offset-minute)))
+ ((or (string= zone "UT") (string= zone "GMT"))
+ nil)
+ ((string= zone "EDT")
+ (setq hour (+ hour 4)))
+ ((or (string= zone "EST") (string= zone "CDT"))
+ (setq hour (+ hour 5)))
+ ((or (string= zone "CST") (string= zone "MDT"))
+ (setq hour (+ hour 6)))
+ ((or (string= zone "MST") (string= zone "PDT"))
+ (setq hour (+ hour 7)))
+ ((string= zone "PST")
+ (setq hour (+ hour 8)))))
(condition-case error-data
(let ((i 1))
(dolist (m '("Jan" "Feb" "Mar" "Apr" "May" "Jun" "Jul" "Aug"
--
2.33.1
^ permalink raw reply related [flat|nested] 5+ messages in thread
* bug#60325: 30.0.50; [PATCH] Fix rfc822 date decode in newsticker
2022-12-25 23:32 bug#60325: 30.0.50; [PATCH] Fix rfc822 date decode in newsticker LdBeth
@ 2022-12-29 9:06 ` Eli Zaretskii
2022-12-30 5:39 ` Paul Eggert
0 siblings, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2022-12-29 9:06 UTC (permalink / raw)
To: LdBeth, Paul Eggert; +Cc: 60325
> Date: Sun, 25 Dec 2022 17:32:45 -0600
> From: LdBeth <andpuke@foxmail.com>
>
> `newsticker--decode-rfc822-date' matches North American timezone in
> regex, but the actually time stamp conversion was not implemented.
> This patch fixes the missing timezone conversion.
Paul, any comments? If not, I intend to install this on master.
Thanks.
> From c06782604df686dd17e6eab5caf64e1717f519dc Mon Sep 17 00:00:00 2001
> From: LdBeth <andpuke@foxmail.com>
> Date: Sun, 25 Dec 2022 17:15:12 -0600
> Subject: [PATCH] Fix newsticker timezone decode
>
> `newsticker--decode-rfc822-date' has the regex pattern for
> North American timezones but the actual timezone conversion
> for them was not implmented. Now cond cases are added to
> handle them as specified in RFC822.
> ---
> lisp/net/newst-backend.el | 20 +++++++++++++++-----
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/lisp/net/newst-backend.el b/lisp/net/newst-backend.el
> index af196cc..2a87742 100644
> --- a/lisp/net/newst-backend.el
> +++ b/lisp/net/newst-backend.el
> @@ -1623,7 +1623,7 @@ Sat, 07 Sep 2002 00:00:01 GMT
> ":\\([0-9]\\{2\\}\\)"
> ;; second
> "\\(:\\([0-9]\\{2\\}\\)\\)?"
> - ;; zone -- fixme
> + ;; zone
> "\\(\\s-+\\("
> "UT\\|GMT\\|EST\\|EDT\\|CST\\|CDT\\|MST\\|MDT\\|PST\\|PDT"
> "\\|\\([-+]\\)\\([0-9]\\{2\\}\\)\\([0-9]\\{2\\}\\)"
> @@ -1642,16 +1642,26 @@ Sat, 07 Sep 2002 00:00:01 GMT
> (offset-hour (read (or (match-string 14 rfc822-string)
> "0")))
> (offset-minute (read (or (match-string 15 rfc822-string)
> - "0")))
> - ;;FIXME
> - )
> + "0"))))
> (when zone
> (cond ((string= sign "+")
> (setq hour (- hour offset-hour))
> (setq minute (- minute offset-minute)))
> ((string= sign "-")
> (setq hour (+ hour offset-hour))
> - (setq minute (+ minute offset-minute)))))
> + (setq minute (+ minute offset-minute)))
> + ((or (string= zone "UT") (string= zone "GMT"))
> + nil)
> + ((string= zone "EDT")
> + (setq hour (+ hour 4)))
> + ((or (string= zone "EST") (string= zone "CDT"))
> + (setq hour (+ hour 5)))
> + ((or (string= zone "CST") (string= zone "MDT"))
> + (setq hour (+ hour 6)))
> + ((or (string= zone "MST") (string= zone "PDT"))
> + (setq hour (+ hour 7)))
> + ((string= zone "PST")
> + (setq hour (+ hour 8)))))
> (condition-case error-data
> (let ((i 1))
> (dolist (m '("Jan" "Feb" "Mar" "Apr" "May" "Jun" "Jul" "Aug"
> --
> 2.33.1
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#60325: 30.0.50; [PATCH] Fix rfc822 date decode in newsticker
2022-12-29 9:06 ` Eli Zaretskii
@ 2022-12-30 5:39 ` Paul Eggert
2022-12-30 14:49 ` Eli Zaretskii
0 siblings, 1 reply; 5+ messages in thread
From: Paul Eggert @ 2022-12-30 5:39 UTC (permalink / raw)
To: Eli Zaretskii, LdBeth; +Cc: 60325-done
[-- Attachment #1: Type: text/plain, Size: 813 bytes --]
On 12/29/22 01:06, Eli Zaretskii wrote:
> Paul, any comments? If not, I intend to install this on master.
It looks OK. I installed it on master for you, and am closing this bug
report.
My only comment is that RFC 822 abbreviations like "EST" have been
officially obsolete ever since RFC 2822 (2001) and are likely to become
simply wrong if the US Congress changes EST to -0400 as it keeps
threatening to do. Current email as a rule doesn't (and obviously
shouldn't) use these obsolete abbreviations. Still, it's helpful to
support them for reading old email archives.
I did a quick pass through Emacs master looking for places where it
generates or encourages the use of obsolete or nonstandard time zone
abbreviations, and installed the attached further patches on master to
fix the issues I found.
[-- Attachment #2: 0001-In-cal-dst-be-consistent-re-default-to-UTC.patch --]
[-- Type: text/x-patch, Size: 2136 bytes --]
From 73769dc2b872441eb0b8565e1090e97fc0b5d521 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 29 Dec 2022 19:16:09 -0800
Subject: [PATCH 1/6] In cal-dst, be consistent re default to UTC
* lisp/calendar/cal-dst.el (calendar-standard-time-zone-name)
(calendar-daylight-time-zone-name):
When using alphabetic time zone abbreviations, default to "UTC"
rather than to "EST" or "EDT", to be consistent with the behavior
when using numeric time zone abbreviations.
Also, in the numeric time zone use "-0000" rather than "+0000"
to show that the time zone is unknown; this is the RFC 5322
standard.
---
lisp/calendar/cal-dst.el | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/lisp/calendar/cal-dst.el b/lisp/calendar/cal-dst.el
index 5f601f24d2..c8a65126a4 100644
--- a/lisp/calendar/cal-dst.el
+++ b/lisp/calendar/cal-dst.el
@@ -354,10 +354,10 @@ calendar-standard-time-zone-name
(if calendar-current-time-zone-cache
(format-time-string
"%z" 0 (* 60 (car calendar-current-time-zone-cache)))
- "+0000")
- (or (nth 2 calendar-current-time-zone-cache) "EST"))
+ "-0000")
+ (or (nth 2 calendar-current-time-zone-cache) "UTC"))
"Abbreviated name of standard time zone at `calendar-location-name'.
-For example, \"EST\" in New York City, \"PST\" for Los Angeles."
+For example, \"-0500\" or \"EST\" in New York City."
:type 'string
:version "28.1"
:set-after '(calendar-time-zone-style)
@@ -368,10 +368,10 @@ calendar-daylight-time-zone-name
(if calendar-current-time-zone-cache
(format-time-string
"%z" 0 (* 60 (cadr calendar-current-time-zone-cache)))
- "+0000")
- (or (nth 3 calendar-current-time-zone-cache) "EDT"))
+ "-0000")
+ (or (nth 3 calendar-current-time-zone-cache) "UTC"))
"Abbreviated name of daylight saving time zone at `calendar-location-name'.
-For example, \"EDT\" in New York City, \"PDT\" for Los Angeles."
+For example, \"-0400\" or \"EDT\" in New York City."
:type 'string
:version "28.1"
:set-after '(calendar-time-zone-style)
--
2.38.1
[-- Attachment #3: 0002-Default-mbox-From-time-zone-to-0000.patch --]
[-- Type: text/x-patch, Size: 1342 bytes --]
From d11e34ce76aac8680337f247419657e042e4cf34 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 29 Dec 2022 21:27:45 -0800
Subject: [PATCH 2/6] Default mbox "From " time zone to -0000
* lisp/mail/rmailout.el (rmail-nuke-pinhead-header):
Default the time zone to "-0000" instead of "EST", as "-0000" is
the RFC-2822-and-later standard for unknown time zones.
---
lisp/mail/rmailout.el | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/lisp/mail/rmailout.el b/lisp/mail/rmailout.el
index c1371308d4..18f980df97 100644
--- a/lisp/mail/rmailout.el
+++ b/lisp/mail/rmailout.el
@@ -327,15 +327,14 @@ rmail-nuke-pinhead-header
"Date: \\2, \\4 \\3 \\9 \\5 "
;; The timezone could be matched by group 7 or group 10.
- ;; If neither of them matched, assume EST, since only
- ;; Easterners would be so sloppy.
+ ;; If neither matched, use "-0000" for an unknown zone.
;; It's a shame the substitution can't use "\\10".
(cond
((/= (match-beginning 7) (match-end 7)) "\\7")
((/= (match-beginning 10) (match-end 10))
(buffer-substring (match-beginning 10)
(match-end 10)))
- (t "EST"))
+ (t "-0000"))
"\n"))
;; Keep and reformat the sender if we don't
;; have a From: field.
--
2.38.1
[-- Attachment #4: 0003-Add-nndiary-headers-obsolescence-comment.patch --]
[-- Type: text/x-patch, Size: 1290 bytes --]
From bc4cbbcc57a56a23c64576c8c23ecf6afb1c747b Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 29 Dec 2022 19:16:09 -0800
Subject: [PATCH 3/6] Add nndiary-headers obsolescence comment
* lisp/gnus/nndiary.el (nndiary-headers): Add comment
about alphabetic time zone names being obsolescent.
---
lisp/gnus/nndiary.el | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/lisp/gnus/nndiary.el b/lisp/gnus/nndiary.el
index ab9c6dd74f..e3fb5d8f87 100644
--- a/lisp/gnus/nndiary.el
+++ b/lisp/gnus/nndiary.el
@@ -339,8 +339,15 @@ nndiary-headers
;; for this header) or one list (specifying all the possible values for this
;; header). In the latter case, the list does NOT include the unspecified
;; spec (*).
+
;; For time zone values, we have symbolic time zone names associated with
;; the (relative) number of seconds ahead GMT.
+ ;; The list of time zone values is obsolescent, and new code should
+ ;; not rely on it. Many of the time zone abbreviations are wrong;
+ ;; in particular, all single-letter abbreviations other than "Z" have
+ ;; been wrong since Internet RFC 2822 (2001). However, the
+ ;; abbreviations have not been changed due to backward compatibility
+ ;; concerns.
)
(defsubst nndiary-schedule ()
--
2.38.1
[-- Attachment #5: 0004-Use-RFC-822-abbrevs-in-sunrise-sunset-strings.patch --]
[-- Type: text/x-patch, Size: 1449 bytes --]
From 007e66bccb2cb8382158e5e24727fd1b4478cd69 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 29 Dec 2022 19:16:09 -0800
Subject: [PATCH 4/6] Use RFC 822 abbrevs in sunrise-sunset strings
* lisp/calendar/solar.el (sunrise-sunset): Use RFC 822 time zone
abbreviations like "+0530" instead of idiosyncratic abbreviations
like "UTC+330min".
---
lisp/calendar/solar.el | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/lisp/calendar/solar.el b/lisp/calendar/solar.el
index 8f501824bb..0b5bc16653 100644
--- a/lisp/calendar/solar.el
+++ b/lisp/calendar/solar.el
@@ -839,12 +839,10 @@ sunrise-sunset
"E" "W"))))))
(calendar-standard-time-zone-name
(if (< arg 16) calendar-standard-time-zone-name
- (cond ((zerop calendar-time-zone)
- (if (eq calendar-time-zone-style 'numeric)
- "+0000" "UTC"))
- ((< calendar-time-zone 0)
- (format "UTC%dmin" calendar-time-zone))
- (t (format "UTC+%dmin" calendar-time-zone)))))
+ (if (and (zerop calendar-time-zone)
+ (not (eq calendar-time-zone-style 'numeric)))
+ "UTC"
+ (format-time-string "%z" 0 (* 60 calendar-time-zone)))))
(calendar-daylight-savings-starts
(if (< arg 16) calendar-daylight-savings-starts))
(calendar-daylight-savings-ends
--
2.38.1
[-- Attachment #6: 0005-Document-calc-time-zone-abbreviation-obsolescence.patch --]
[-- Type: text/x-patch, Size: 1755 bytes --]
From 523261b454058d0b28df2c3de1eab55fe378aa69 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 29 Dec 2022 19:16:09 -0800
Subject: [PATCH 5/6] Document calc-time-zone abbreviation obsolescence
* doc/misc/calc.texi (Time Zones): Document that alphabetic
time zone abbreviations are obsolescent and in some cases wrong.
---
doc/misc/calc.texi | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/doc/misc/calc.texi b/doc/misc/calc.texi
index ef9990c057..e5bac25cac 100644
--- a/doc/misc/calc.texi
+++ b/doc/misc/calc.texi
@@ -17341,8 +17341,12 @@ Time Zones
For example @samp{tzone(PST) = tzone(8)} and @samp{tzone(pdt) = tzone(7)}
(for Pacific standard and daylight saving times, respectively).
-North American and European time zone names are defined as follows;
-note that for each time zone there is one name for standard time,
+North American and European time zone names are defined as follows.
+These names are obsolescent and new code should not rely on them:
+the @samp{YST}-related names have disagreed with time in Yukon since 1973,
+and other names could well become confusing or wrong in the future
+as countries change their time zone rules.
+For each time zone there is one name for standard time,
another for daylight saving time, and a third for ``generalized'' time
in which the daylight saving adjustment is computed from context.
@@ -17364,7 +17368,7 @@ Time Zones
you must modify the Lisp variable @code{math-tzone-names}. This
is a list of lists describing the different time zone names; its
structure is best explained by an example. The three entries for
-Pacific Time look like this:
+circa-2022 US Pacific Time look like this:
@smallexample
@group
--
2.38.1
[-- Attachment #7: 0006-Avoid-some-obsolescent-tz-abbrevs-in-doc.patch --]
[-- Type: text/x-patch, Size: 2170 bytes --]
From 9153cf8158489d387a6a0d9d0ede9a2528c35f0a Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 29 Dec 2022 19:16:10 -0800
Subject: [PATCH 6/6] Avoid some obsolescent tz abbrevs in doc.
---
doc/misc/mh-e.texi | 2 +-
doc/misc/sc.texi | 4 ++--
lisp/calendar/diary-lib.el | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/misc/mh-e.texi b/doc/misc/mh-e.texi
index 1a80c62edb..0650ad69a8 100644
--- a/doc/misc/mh-e.texi
+++ b/doc/misc/mh-e.texi
@@ -793,7 +793,7 @@ Reading Mail Tour
@cartouche
@smallexample
- 3 t08/24 root received fax files on Wed Aug 24 11:00:13 PDT 1
+ 3 t08/24 root received fax files on Wed Aug 24 11:00:13 -0700 1
# 4+t08/24 To:wohler Test<<This is a test message to get the wheels
-:%% @{+inbox/select@} 4 msgs (1-4) Bot L4 (MH-Folder Show)---------
diff --git a/doc/misc/sc.texi b/doc/misc/sc.texi
index 3f6dcd022a..49c86f6812 100644
--- a/doc/misc/sc.texi
+++ b/doc/misc/sc.texi
@@ -404,7 +404,7 @@ Information Keys and the Info Alist
following fields were present in the original article:
@example
-Date:@: 08 April 1991, 17:32:09 EST
+Date:@: 08 Apr 1991 17:32:09 -0500
Subject:@: Better get out your asbestos suit
@end example
@@ -415,7 +415,7 @@ Information Keys and the Info Alist
@example
(sc-mail-field "date")
-==> "08 April 1991, 17:32:09 EST"
+==> "08 Apr 1991 17:32:09 -0500"
(sc-mail-field "subject")
==> "Better get out your asbestos suit"
diff --git a/lisp/calendar/diary-lib.el b/lisp/calendar/diary-lib.el
index 9a2baf1e43..cc1e7ec5f7 100644
--- a/lisp/calendar/diary-lib.el
+++ b/lisp/calendar/diary-lib.el
@@ -339,7 +339,7 @@ diary-outlook-format-1
(t "\\1 \\2 \\3"))) ; MDY
"\n \\4 %s, \\5")))
;; TODO Sometimes the time is in a different time-zone to the one you
-;; are in. Eg in PST, you might still get an email referring to:
+;; are in. E.g., in Los Angeles, you might still get an email referring to:
;; "7:00 PM-8:00 PM. Greenwich Standard Time".
;; Note that it doesn't use a standard abbreviation for the timezone,
;; or anything helpful like that.
--
2.38.1
^ permalink raw reply related [flat|nested] 5+ messages in thread
* bug#60325: 30.0.50; [PATCH] Fix rfc822 date decode in newsticker
2022-12-30 5:39 ` Paul Eggert
@ 2022-12-30 14:49 ` Eli Zaretskii
2022-12-31 8:46 ` Paul Eggert
0 siblings, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2022-12-30 14:49 UTC (permalink / raw)
To: Paul Eggert; +Cc: andpuke, 60325-done
> Date: Thu, 29 Dec 2022 21:39:11 -0800
> Cc: 60325-done@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
>
> On 12/29/22 01:06, Eli Zaretskii wrote:
> > Paul, any comments? If not, I intend to install this on master.
>
> It looks OK. I installed it on master for you, and am closing this bug
> report.
Thanks.
> I did a quick pass through Emacs master looking for places where it
> generates or encourages the use of obsolete or nonstandard time zone
> abbreviations, and installed the attached further patches on master to
> fix the issues I found.
Are you sure this doesn't break MS-Windows? AFAIUK, Windows tz
functions don't support UTC, they only support the old style RFC 822
abbreviations.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#60325: 30.0.50; [PATCH] Fix rfc822 date decode in newsticker
2022-12-30 14:49 ` Eli Zaretskii
@ 2022-12-31 8:46 ` Paul Eggert
0 siblings, 0 replies; 5+ messages in thread
From: Paul Eggert @ 2022-12-31 8:46 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: andpuke, 60325
On 2022-12-30 06:49, Eli Zaretskii wrote:
>> I did a quick pass through Emacs master looking for places where it
>> generates or encourages the use of obsolete or nonstandard time zone
>> abbreviations, and installed the attached further patches on master to
>> fix the issues I found.
> Are you sure this doesn't break MS-Windows? AFAIUK, Windows tz
> functions don't support UTC, they only support the old style RFC 822
> abbreviations.
The MS-Windows documentation says TZ='UTC0' should support UTC
<https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/tzset>.
However, most likely I'm misunderstanding the scenario you are thinking
of, as I don't see the connection between your comment and the further
patches I installed.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-12-31 8:46 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-25 23:32 bug#60325: 30.0.50; [PATCH] Fix rfc822 date decode in newsticker LdBeth
2022-12-29 9:06 ` Eli Zaretskii
2022-12-30 5:39 ` Paul Eggert
2022-12-30 14:49 ` Eli Zaretskii
2022-12-31 8:46 ` Paul Eggert
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.