[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
From: |
Bob Rogers |
Subject: |
bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates |
Date: |
Thu, 30 Dec 2021 00:32:49 -0500 |
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
--- 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.
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, (continued)
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Bob Rogers, 2021/12/23
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Lars Ingebrigtsen, 2021/12/24
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Bob Rogers, 2021/12/24
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Lars Ingebrigtsen, 2021/12/25
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Bob Rogers, 2021/12/25
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Lars Ingebrigtsen, 2021/12/26
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Bob Rogers, 2021/12/28
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Lars Ingebrigtsen, 2021/12/29
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Paul Eggert, 2021/12/29
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Bob Rogers, 2021/12/29
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates,
Bob Rogers <=
- bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates, Bob Rogers, 2021/12/30