
[Extracts from RFC2822]

[...]

3.3. Date and Time Specification

   Date and time 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
   space correctly.

date-time       =       [ day-of-week "," ] date FWS time [CFWS]

day-of-week     =       ([FWS] day-name) / obs-day-of-week

day-name        =       "Mon" / "Tue" / "Wed" / "Thu" /
                        "Fri" / "Sat" / "Sun"

date            =       day month year

year            =       4*DIGIT / obs-year

month           =       (FWS month-name FWS) / obs-month

month-name      =       "Jan" / "Feb" / "Mar" / "Apr" /
                        "May" / "Jun" / "Jul" / "Aug" /
                        "Sep" / "Oct" / "Nov" / "Dec"

day             =       ([FWS] 1*2DIGIT) / obs-day

time            =       time-of-day FWS zone

time-of-day     =       hour ":" minute [ ":" second ]

hour            =       2DIGIT / obs-hour

minute          =       2DIGIT / obs-minute

second          =       2DIGIT / obs-second

zone            =       (( "+" / "-" ) 4DIGIT) / obs-zone

   The day is the numeric day of the month.  The year is any numeric
   year 1900 or later.

   The time-of-day specifies the number of hours, minutes, and
   optionally seconds since midnight of the date indicated.

   The date and time-of-day SHOULD express local time.

   The zone specifies the offset from Coordinated Universal Time (UTC,
   formerly referred to as "Greenwich Mean Time") that the date and
   time-of-day represent.  The "+" or "-" indicates whether the
   time-of-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 +(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 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 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.

[...]

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 permits comments and folding white space between many of the
   tokens.

obs-day-of-week =       [CFWS] day-name [CFWS]

obs-year        =       [CFWS] 2*DIGIT [CFWS]

obs-month       =       CFWS month-name CFWS

obs-day         =       [CFWS] 1*2DIGIT [CFWS]

obs-hour        =       [CFWS] 2DIGIT [CFWS]

obs-minute      =       [CFWS] 2DIGIT [CFWS]

obs-second      =       [CFWS] 2DIGIT [CFWS]

obs-zone        =       "UT" / "GMT" /          ; Universal Time
                                                ; North American UT
                                                ; offsets
                        "EST" / "EDT" /         ; Eastern:  - 5/ - 4
                        "CST" / "CDT" /         ; Central:  - 6/ - 5
                        "MST" / "MDT" /         ; Mountain: - 7/ - 6
                        "PST" / "PDT" /         ; Pacific:  - 8/ - 7

                        %d65-73 /               ; Military zones - "A"
                        %d75-90 /               ; through "I" and "K"
                        %d97-105 /              ; through "Z", both
                        %d107-122               ; upper and lower case

   Where a two or three digit year occurs in a date, the year is to be
   interpreted as follows: If a two digit year is encountered whose
   value is between 00 and 49, the year is interpreted by adding 2000,
   ending up with a value between 2000 and 2049.  If a two digit year is
   encountered with a value between 50 and 99, or any three digit year
   is encountered, the year is interpreted by adding 1900.

   In the obsolete time zone, "UT" and "GMT" are indications of
   "Universal Time" and "Greenwich Mean Time" respectively and are both
   semantically identical to "+0000".

   The remaining three character zones are the US time zones.  The first
   letter, "E", "C", "M", or "P" stands for "Eastern", "Central",
   "Mountain" and "Pacific".  The second letter is either "S" for
   "Standard" time, or "D" for "Daylight" (or summer) time.  Their
   interpretations are as follows:

   EDT is semantically equivalent to -0400
   EST is semantically equivalent to -0500
   CDT is semantically equivalent to -0500
   CST is semantically equivalent to -0600
   MDT is semantically equivalent to -0600
   MST is semantically equivalent to -0700
   PDT is semantically equivalent to -0700
   PST is semantically equivalent to -0800

   The 1 character military time zones were defined in a non-standard
   way in [RFC822] and are therefore unpredictable in their meaning.
   The original definitions of the military zones "A" through "I" are
   equivalent to "+0100" through "+0900" respectively; "K", "L", and "M"
   are equivalent to  "+1000", "+1100", and "+1200" respectively; "N"
   through "Y" are equivalent to "-0100" through "-1200" respectively;
   and "Z" is equivalent to "+0000".  However, because of the error in
   [RFC822], 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.

[...]

Appendix B. Differences from earlier standards

   This appendix contains a list of changes that have been made in the
   Internet Message Format from earlier standards, specifically [RFC822]
   and [STD3].  Items marked with an asterisk (*) below are items which
   appear in section 4 of this document and therefore can no longer be
   generated.

   1. Period allowed in obsolete form of phrase.
   2. ABNF moved out of document to [RFC2234].
   3. Four or more digits allowed for year.
   4. Header field ordering (and lack thereof) made explicit.
   5. Encrypted header field removed.
   6. Received syntax loosened to allow any token/value pair.
   7. Specifically allow and give meaning to "-0000" time zone.
   8. Folding white space is not allowed between every token.
   9. Requirement for destinations removed.
   10. Forwarding and resending redefined.
   11. Extension header fields no longer specifically called out.
   12. ASCII 0 (null) removed.*
   13. Folding continuation lines cannot contain only white space.*
   14. Free insertion of comments not allowed in date.*
   15. Non-numeric time zones not allowed.*
   16. Two digit years not allowed.*
   17. Three digit years interpreted, but not allowed for generation.
   18. Routes in addresses not allowed.*
   19. CFWS within local-parts and domains not allowed.*
   20. Empty members of address lists not allowed.*
   21. Folding white space between field name and colon not allowed.*
   22. Comments between field name and colon not allowed.
   23. Tightened syntax of in-reply-to and references.*
   24. CFWS within msg-id not allowed.*
   25. Tightened semantics of resent fields as informational only.
   26. Resent-Reply-To not allowed.*
   27. No multiple occurrences of fields (except resent and received).*
   28. Free CR and LF not allowed.*
   29. Routes in return path not allowed.*
   30. Line length limits specified.
   31. Bcc more clearly specified.

[...]

Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

[...]
