← Back to branch summary

~ubuntu-branches/ubuntu/saucy/libdatetime-format-mail-perl/saucy

« back to all changes in this revision

Viewing changes to notes/rfc2822.txt

  • Committer: Bazaar Package Importer
  • Author(s): Damyan Ivanov, Damyan Ivanov, Joey Hess
  • Date: 2007-09-11 12:31:45 UTC
  • mfrom: (1.1.1 upstream)
  • Revision ID: james.westby@ubuntu.com-20070911123145-qkfgsouaxwjubrl4
Tags: 0.3001-1
[ Damyan Ivanov ]
* New upstream release
  No longer includes non-free IETF RFCs
* Added myself to Uploaders (and wrapped it)
* debian/rules:
  + Dropped unused dh_* calls
  + Moved dh_clean $stamp_files before the distclean call
  + Do not ignore distclean errors
  + Drop unneeded OPTIMIZE="..." setting
* Moved libmodule-build-perl from B-D-I to B-D

[ Joey Hess ]
* Fix watch file to deal with mangled version number.

Show diffs side-by-side

added added

removed removed

Lines of Context:
notes/rfc2822.txt
1
 
 
2
 
[Extracts from RFC2822]
3
 
 
4
 
[...]
5
 
 
6
 
3.3. Date and Time Specification
7
 
 
8
 
   Date and time occur in several header fields.  This section specifies
9
 
   the syntax for a full date and time specification.  Though folding
10
 
   white space is permitted throughout the date-time specification, it
11
 
   is RECOMMENDED that a single space be used in each place that FWS
12
 
   appears (whether it is required or optional); some older
13
 
   implementations may not interpret other occurrences of folding white
14
 
   space correctly.
15
 
 
16
 
date-time       =       [ day-of-week "," ] date FWS time [CFWS]
17
 
 
18
 
day-of-week     =       ([FWS] day-name) / obs-day-of-week
19
 
 
20
 
day-name        =       "Mon" / "Tue" / "Wed" / "Thu" /
21
 
                        "Fri" / "Sat" / "Sun"
22
 
 
23
 
date            =       day month year
24
 
 
25
 
year            =       4*DIGIT / obs-year
26
 
 
27
 
month           =       (FWS month-name FWS) / obs-month
28
 
 
29
 
month-name      =       "Jan" / "Feb" / "Mar" / "Apr" /
30
 
                        "May" / "Jun" / "Jul" / "Aug" /
31
 
                        "Sep" / "Oct" / "Nov" / "Dec"
32
 
 
33
 
day             =       ([FWS] 1*2DIGIT) / obs-day
34
 
 
35
 
time            =       time-of-day FWS zone
36
 
 
37
 
time-of-day     =       hour ":" minute [ ":" second ]
38
 
 
39
 
hour            =       2DIGIT / obs-hour
40
 
 
41
 
minute          =       2DIGIT / obs-minute
42
 
 
43
 
second          =       2DIGIT / obs-second
44
 
 
45
 
zone            =       (( "+" / "-" ) 4DIGIT) / obs-zone
46
 
 
47
 
   The day is the numeric day of the month.  The year is any numeric
48
 
   year 1900 or later.
49
 
 
50
 
   The time-of-day specifies the number of hours, minutes, and
51
 
   optionally seconds since midnight of the date indicated.
52
 
 
53
 
   The date and time-of-day SHOULD express local time.
54
 
 
55
 
   The zone specifies the offset from Coordinated Universal Time (UTC,
56
 
   formerly referred to as "Greenwich Mean Time") that the date and
57
 
   time-of-day represent.  The "+" or "-" indicates whether the
58
 
   time-of-day is ahead of (i.e., east of) or behind (i.e., west of)
59
 
   Universal Time.  The first two digits indicate the number of hours
60
 
   difference from Universal Time, and the last two digits indicate the
61
 
   number of minutes difference from Universal Time.  (Hence, +hhmm
62
 
   means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm)
63
 
   minutes).  The form "+0000" SHOULD be used to indicate a time zone at
64
 
   Universal Time.  Though "-0000" also indicates Universal Time, it is
65
 
   used to indicate that the time was generated on a system that may be
66
 
   in a local time zone other than Universal Time and therefore
67
 
   indicates that the date-time contains no information about the local
68
 
   time zone.
69
 
 
70
 
   A date-time specification MUST be semantically valid.  That is, the
71
 
   day-of-the-week (if included) MUST be the day implied by the date,
72
 
   the numeric day-of-month MUST be between 1 and the number of days
73
 
   allowed for the specified month (in the specified year), the
74
 
   time-of-day MUST be in the range 00:00:00 through 23:59:60 (the
75
 
   number of seconds allowing for a leap second; see [STD12]), and the
76
 
   zone MUST be within the range -9959 through +9959.
77
 
 
78
 
[...]
79
 
 
80
 
4.3. Obsolete Date and Time
81
 
 
82
 
   The syntax for the obsolete date format allows a 2 digit year in the
83
 
   date field and allows for a list of alphabetic time zone
84
 
   specifications that were used in earlier versions of this standard.
85
 
   It also permits comments and folding white space between many of the
86
 
   tokens.
87
 
 
88
 
obs-day-of-week =       [CFWS] day-name [CFWS]
89
 
 
90
 
obs-year        =       [CFWS] 2*DIGIT [CFWS]
91
 
 
92
 
obs-month       =       CFWS month-name CFWS
93
 
 
94
 
obs-day         =       [CFWS] 1*2DIGIT [CFWS]
95
 
 
96
 
obs-hour        =       [CFWS] 2DIGIT [CFWS]
97
 
 
98
 
obs-minute      =       [CFWS] 2DIGIT [CFWS]
99
 
 
100
 
obs-second      =       [CFWS] 2DIGIT [CFWS]
101
 
 
102
 
obs-zone        =       "UT" / "GMT" /          ; Universal Time
103
 
                                                ; North American UT
104
 
                                                ; offsets
105
 
                        "EST" / "EDT" /         ; Eastern:  - 5/ - 4
106
 
                        "CST" / "CDT" /         ; Central:  - 6/ - 5
107
 
                        "MST" / "MDT" /         ; Mountain: - 7/ - 6
108
 
                        "PST" / "PDT" /         ; Pacific:  - 8/ - 7
109
 
 
110
 
                        %d65-73 /               ; Military zones - "A"
111
 
                        %d75-90 /               ; through "I" and "K"
112
 
                        %d97-105 /              ; through "Z", both
113
 
                        %d107-122               ; upper and lower case
114
 
 
115
 
   Where a two or three digit year occurs in a date, the year is to be
116
 
   interpreted as follows: If a two digit year is encountered whose
117
 
   value is between 00 and 49, the year is interpreted by adding 2000,
118
 
   ending up with a value between 2000 and 2049.  If a two digit year is
119
 
   encountered with a value between 50 and 99, or any three digit year
120
 
   is encountered, the year is interpreted by adding 1900.
121
 
 
122
 
   In the obsolete time zone, "UT" and "GMT" are indications of
123
 
   "Universal Time" and "Greenwich Mean Time" respectively and are both
124
 
   semantically identical to "+0000".
125
 
 
126
 
   The remaining three character zones are the US time zones.  The first
127
 
   letter, "E", "C", "M", or "P" stands for "Eastern", "Central",
128
 
   "Mountain" and "Pacific".  The second letter is either "S" for
129
 
   "Standard" time, or "D" for "Daylight" (or summer) time.  Their
130
 
   interpretations are as follows:
131
 
 
132
 
   EDT is semantically equivalent to -0400
133
 
   EST is semantically equivalent to -0500
134
 
   CDT is semantically equivalent to -0500
135
 
   CST is semantically equivalent to -0600
136
 
   MDT is semantically equivalent to -0600
137
 
   MST is semantically equivalent to -0700
138
 
   PDT is semantically equivalent to -0700
139
 
   PST is semantically equivalent to -0800
140
 
 
141
 
   The 1 character military time zones were defined in a non-standard
142
 
   way in [RFC822] and are therefore unpredictable in their meaning.
143
 
   The original definitions of the military zones "A" through "I" are
144
 
   equivalent to "+0100" through "+0900" respectively; "K", "L", and "M"
145
 
   are equivalent to  "+1000", "+1100", and "+1200" respectively; "N"
146
 
   through "Y" are equivalent to "-0100" through "-1200" respectively;
147
 
   and "Z" is equivalent to "+0000".  However, because of the error in
148
 
   [RFC822], they SHOULD all be considered equivalent to "-0000" unless
149
 
   there is out-of-band information confirming their meaning.
150
 
 
151
 
   Other multi-character (usually between 3 and 5) alphabetic time zones
152
 
   have been used in Internet messages.  Any such time zone whose
153
 
   meaning is not known SHOULD be considered equivalent to "-0000"
154
 
   unless there is out-of-band information confirming their meaning.
155
 
 
156
 
[...]
157
 
 
158
 
Appendix B. Differences from earlier standards
159
 
 
160
 
   This appendix contains a list of changes that have been made in the
161
 
   Internet Message Format from earlier standards, specifically [RFC822]
162
 
   and [STD3].  Items marked with an asterisk (*) below are items which
163
 
   appear in section 4 of this document and therefore can no longer be
164
 
   generated.
165
 
 
166
 
   1. Period allowed in obsolete form of phrase.
167
 
   2. ABNF moved out of document to [RFC2234].
168
 
   3. Four or more digits allowed for year.
169
 
   4. Header field ordering (and lack thereof) made explicit.
170
 
   5. Encrypted header field removed.
171
 
   6. Received syntax loosened to allow any token/value pair.
172
 
   7. Specifically allow and give meaning to "-0000" time zone.
173
 
   8. Folding white space is not allowed between every token.
174
 
   9. Requirement for destinations removed.
175
 
   10. Forwarding and resending redefined.
176
 
   11. Extension header fields no longer specifically called out.
177
 
   12. ASCII 0 (null) removed.*
178
 
   13. Folding continuation lines cannot contain only white space.*
179
 
   14. Free insertion of comments not allowed in date.*
180
 
   15. Non-numeric time zones not allowed.*
181
 
   16. Two digit years not allowed.*
182
 
   17. Three digit years interpreted, but not allowed for generation.
183
 
   18. Routes in addresses not allowed.*
184
 
   19. CFWS within local-parts and domains not allowed.*
185
 
   20. Empty members of address lists not allowed.*
186
 
   21. Folding white space between field name and colon not allowed.*
187
 
   22. Comments between field name and colon not allowed.
188
 
   23. Tightened syntax of in-reply-to and references.*
189
 
   24. CFWS within msg-id not allowed.*
190
 
   25. Tightened semantics of resent fields as informational only.
191
 
   26. Resent-Reply-To not allowed.*
192
 
   27. No multiple occurrences of fields (except resent and received).*
193
 
   28. Free CR and LF not allowed.*
194
 
   29. Routes in return path not allowed.*
195
 
   30. Line length limits specified.
196
 
   31. Bcc more clearly specified.
197
 
 
198
 
[...]
199
 
 
200
 
Full Copyright Statement
201
 
 
202
 
   Copyright (C) The Internet Society (2001).  All Rights Reserved.
203
 
 
204
 
   This document and translations of it may be copied and furnished to
205
 
   others, and derivative works that comment on or otherwise explain it
206
 
   or assist in its implementation may be prepared, copied, published
207
 
   and distributed, in whole or in part, without restriction of any
208
 
   kind, provided that the above copyright notice and this paragraph are
209
 
   included on all such copies and derivative works.  However, this
210
 
   document itself may not be modified in any way, such as by removing
211
 
   the copyright notice or references to the Internet Society or other
212
 
   Internet organizations, except as needed for the purpose of
213
 
   developing Internet standards in which case the procedures for
214
 
   copyrights defined in the Internet Standards process must be
215
 
   followed, or as required to translate it into languages other than
216
 
   English.
217
 
 
218
 
   The limited permissions granted above are perpetual and will not be
219
 
   revoked by the Internet Society or its successors or assigns.
220
 
 
221
 
   This document and the information contained herein is provided on an
222
 
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
223
 
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
224
 
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
225
 
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
226
 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
227
 
 
228
 
[...]