unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Bob Rogers <rogers-emacs@rgrjr.homedns.org>
To: Paul Eggert <eggert@cs.ucla.edu>,
	Lars Ingebrigtsen <larsi@gnus.org>,
	52209@debbugs.gnu.org
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Date: Thu, 30 Dec 2021 00:32:49 -0500	[thread overview]
Message-ID: <25037.17537.313178.136412@orion.rgrjr.com> (raw)
In-Reply-To: <25036.55965.149104.938898@orion.rgrjr.com>

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 1002 bytes --]

   From: Bob Rogers <rogers-emacs@rgrjr.homedns.org>
   Date: Wed, 29 Dec 2021 17:01:01 -0500

      From: Paul Eggert <eggert@cs.ucla.edu>
      Date: Wed, 29 Dec 2021 11:29:44 -0800

      * I suggest preferring the symbol 'rfc-email' for parsing
      email-related dates, for consistency with the --rfc-email option
      of GNU 'date'. This should use the current RFC (5322 now, perhaps
      updated later).

The only update I saw at https://www.rfc-editor.org (RFC6854) only
affects addressing syntax.

   I started with RFC822 and RFC2822 because I had copies of these lying
   around; you're right that I should have looked for more recent
   standards.  And using rfc-email as a synonym for the latest version is a
   good idea.

FYI, there is no substantial difference between RFC2822 and RFC5322 in
date/time syntax.  They hide the whitespace in different productions,
but the end result is the same.  So I'll change the format name to
rfc5322 and add rfc-email as a synonym.

					-- Bob


[-- Attachment #2: Type: text/x-patch, Size: 4132 bytes --]

--- rfc2822-date.text	2021-12-30 00:15:38.588023882 -0500
+++ rfc5322-date.text	2021-12-29 23:41:39.492629354 -0500
@@ -1,15 +1,15 @@
 
 3.3. Date and Time Specification
 
- Date and time occur in several header fields. This section
+ Date and time values occur in several header fields. This section
  specifies the syntax for a full date and time specification. Though
  folding white space is permitted throughout the date-time
  specification, it is RECOMMENDED that a single space be used in each
  place that FWS appears (whether it is required or optional); some older
- implementations may not interpret other occurrences of folding white
+ implementations will not interpret longer sequences of folding white
  space correctly.
 
- date-time = [ day-of-week "," ] date FWS time [CFWS]
+ date-time = [ day-of-week "," ] date time [CFWS]
 
  day-of-week = ([FWS] day-name) / obs-day-of-week
 
@@ -18,17 +18,15 @@
 
  date = day month year
 
- day = ([FWS] 1*2DIGIT) / obs-day
+ day = ([FWS] 1*2DIGIT FWS) / obs-day
 
- month = (FWS month-name FWS) / obs-month
-
- month-name = "Jan" / "Feb" / "Mar" / "Apr" /
+ month = "Jan" / "Feb" / "Mar" / "Apr" /
  "May" / "Jun" / "Jul" / "Aug" /
  "Sep" / "Oct" / "Nov" / "Dec"
 
- year = 4*DIGIT / obs-year
+ year = (FWS 4*DIGIT FWS) / obs-year
 
- time = time-of-day FWS zone
+ time = time-of-day zone
 
  time-of-day = hour ":" minute [ ":" second ]
 
@@ -38,7 +36,7 @@
 
  second = 2DIGIT / obs-second
 
- zone = (( "+" / "-" ) 4DIGIT) / obs-zone
+ zone = (FWS ( "+" / "-" ) 4DIGIT) / obs-zone
 
  The day is the numeric day of the month. The year is any numeric year
  1900 or later.
@@ -54,28 +52,27 @@
  day is ahead of (i.e., east of) or behind (i.e., west of) Universal
  Time. The first two digits indicate the number of hours difference from
  Universal Time, and the last two digits indicate the number of
- minutes difference from Universal Time. (Hence, +hhmm means
+ additional minutes difference from Universal Time. (Hence, +hhmm means
  +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm) minutes). The
  form "+0000" SHOULD be used to indicate a time zone at Universal
  Time. Though "-0000" also indicates Universal Time, it is used to
  indicate that the time was generated on a system that may be in a local
- time zone other than Universal Time and therefore indicates that the
- date-time contains no
+ time zone other than Universal Time and that the date-time contains no
  information about the local time zone.
 
  A date-time specification MUST be semantically valid. That is, the
- day-of-the-week (if included) MUST be the day implied by the date, the
+ day-of-week (if included) MUST be the day implied by the date, the
  numeric day-of-month MUST be between 1 and the number of days allowed
  for the specified month (in the specified year), the time-of-day MUST
  be in the range 00:00:00 through 23:59:60 (the number of seconds
- allowing for a leap second; see [STD12]), and the zone MUST be within
- the range -9959 through +9959.
+ allowing for a leap second; see [RFC1305]), and the last two digits of
+ the zone MUST be within the range 00 through 59.
 
 4.3. Obsolete Date and Time
 
  The syntax for the obsolete date format allows a 2 digit year in the
- date field and allows for a list of alphabetic time zone specifications
- that were used in earlier versions of this standard. It also
+ date field and allows for a list of alphabetic time zone specifiers
+ that were used in earlier versions of this specification. It also
  permits comments and folding white space between many of the tokens.
 
  obs-day-of-week = [CFWS] day-name [CFWS]
@@ -138,3 +135,8 @@
  and "Z" is equivalent to "+0000". However, because of the error in
  [RFC0822], they SHOULD all be considered equivalent to "-0000" unless
  there is out-of-band information confirming their meaning.
+
+ Other multi-character (usually between 3 and 5) alphabetic time zones
+ have been used in Internet messages. Any such time zone whose meaning
+ is not known SHOULD be considered equivalent to "-0000" unless there is
+ out-of-band information confirming their meaning.

  reply	other threads:[~2021-12-30  5:32 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-30 20:55 bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates Bob Rogers
2021-12-01  4:17 ` Lars Ingebrigtsen
2021-12-03  5:19   ` Katsumi Yamaoka
2021-12-03 16:29     ` Lars Ingebrigtsen
2021-12-03 18:38     ` Michael Heerdegen
2021-12-04 18:58 ` Paul Eggert
2021-12-19 21:11   ` Bob Rogers
2021-12-20 10:08     ` Lars Ingebrigtsen
2021-12-20 15:57       ` Bob Rogers
2021-12-20 16:34         ` Bob Rogers
2021-12-21 11:01         ` Lars Ingebrigtsen
2021-12-23 19:48           ` Bob Rogers
2021-12-24  9:29             ` Lars Ingebrigtsen
2021-12-24 15:58               ` Bob Rogers
2021-12-25 11:58                 ` Lars Ingebrigtsen
2021-12-25 22:50                   ` Bob Rogers
2021-12-26 11:31                     ` Lars Ingebrigtsen
2021-12-28 15:52                       ` Bob Rogers
2021-12-29 15:19                         ` Lars Ingebrigtsen
2021-12-29 19:29                           ` Paul Eggert
2021-12-29 22:01                             ` Bob Rogers
2021-12-30  5:32                               ` Bob Rogers [this message]
2021-12-30 21:08                           ` Bob Rogers
2022-01-01 14:47                             ` Lars Ingebrigtsen
2022-01-01 14:56                               ` Andreas Schwab
2022-01-02  0:41                                 ` Bob Rogers
2022-01-03 11:34                                   ` Lars Ingebrigtsen
2022-01-04  4:45                                     ` Bob Rogers
2022-01-05 15:46                                       ` Lars Ingebrigtsen
2022-01-05 22:49                                         ` Bob Rogers
     [not found]                                           ` <25105.33397.961104.269676@orion.rgrjr.com>
2022-02-20 12:25                                             ` Lars Ingebrigtsen
2022-02-20 13:03                                             ` Andreas Schwab
     [not found]                                               ` <87ilt9vicd.fsf@gnus.org>
2022-02-20 22:14                                                 ` Bob Rogers
2022-02-23 23:15                                                   ` Bob Rogers
2022-02-24  9:19                                                     ` Lars Ingebrigtsen
2022-02-25  0:49                                                       ` Bob Rogers
2022-02-25  2:16                                                         ` Lars Ingebrigtsen
2022-02-25  2:32                                                           ` Bob Rogers
2022-02-25  2:58                                                             ` Bob Rogers
2022-02-25 12:03                                                               ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=25037.17537.313178.136412@orion.rgrjr.com \
    --to=rogers-emacs@rgrjr.homedns.org \
    --cc=52209@debbugs.gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=larsi@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).