From: Paul Overell (paulo@turnpike.com)
Date: Tue Jun 13 2000 - 09:57:18 CDT
In article <Fw36qH.FIL@clw.cs.man.ac.uk>, Charles Lindsey
<chl@clw.cs.man.ac.uk> writes
>In <KZbTwLA$USR5QAsM@turnpike.com> Paul Overell <paulo@turnpike.com> writes:
>
>>As I proposed it I'd better vote for this one!
>
>>The algorithm needs a bit of tweaking in order to make it more re-write
>>proof:
>
>> The day must not have a leading zero.
>>
>> The case of the month needs to be canonicalized, all lowercase?
>
>> If missing, the optional seconds field must be added as :00.
>
>> If a two digit year is given it must be changed into a four
>> digit year as per [MESSFOR].
>
>OK, how about:
>
>Any date-time occurring in a Date, Resent-Date or Expires header (but not in
>any other header) is converted to UTC (i.e. to timezone +0000, specifically
>with a "+" as opposed to a "-"), its day-of-week field, if present, is
>removed, any leading '0' in its day field is removed, its month-name is
>converted to lower case, and any 2-digit year is expanded to 4 digits.
>
>What a horrible mess! Sounds like another argument for preferring option
>1 to me.
>
OK, instead of giving an algorithm try specifying syntax. (This more
reflects my original proposal of a restricted [MESSFOR] date-time rather
than your example.)
Any date-time occurring in a Date, Resent-Date or Expires header (but
not in any other header) is converted to the canonical-date-time that
corresponds to the same point in time. A canonical-date-time is a legal
[MESSFOR] date-time but is so restricted such that there is exactly one
unique canonical-date-time for each second of time.
canonical-date-time = can-day SP can-month SP can-year SP
can-hour ":" can-minute ":" can-second SP
can-zone
can-day = 2DIGIT
can-month = month; from [MESSFOR], all lower-case
can-year = 4DIGIT
can-hour = 2DIGIT
can-minute = 2DIGIT
can-second = 2DIGIT
can-zone = "-0000"
>>>> NOTE: Observe that the effect is to treat "31 Dec 2000 23:59:60
>>>> +0000" (which is a legitimate date-time as defined by [MESSFOR])
>>>> as being different from "1 Jan 2001 00:00:00 +0000".
>>>
>
>>I don't think that it has been announced yet whether or not there will
>>be a leap second at the end of this year, so perhaps use a different
>>real example e.g. 1998?
>
>That is irrelevant. If someone (perhaps erroneously) chooses to construct
>that date, then the algorithm will cope like it just said.
>
My point here is that RFCs don't usually say what to do with broken
messages. A fictitious leap-second is as broken as 31 Feb. Our
examples should not be broken. The fact that the algorithm can cope
with such broken messages is irrelevant.
Regards
-- Paul Overell T U R N P I K E