Re: Issue 163, was: Meaning of invalid but well-formed dates

Brian Smith wrote:
> Dan Winship wrote:
>> Julian Reschke wrote:
>>> That being said, changing a normative requirement from RFC2616, even
>>> if it's underspecified, is something we shouldn't do lightly.
>> Has anyone even seen an rfc850-date in the wild recently?
> 
> No, and I think the MUST-level requirement should be reduced to SHOULD for
> that reason. It is analogous to the situation with line folding.
> 
> I just found that the semantics of two-digit dates are defined already in
> Part 1, Appendix A, which used to be RFC 2616 Section 19.3. That statement
> should be moved up to section 3.2 with the rest of date syntax and
> semantics. 

Good catch, but what a mess:

     * HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date 
which appears to be more than 50 years in the future is in fact in the 
past (this helps solve the "year 2000" problem).

-> 50 years from when? Does the semantics of the message depend on when 
you look at it?

     * If an HTTP header incorrectly carries a date value with a time 
zone other than GMT, it MUST be converted into GMT using the most 
conservative possible conversion.

-> What exactly is the "most conservative conversion"?

It would be extremely useful to find out how deployed code handles these 
cases; either there is common handling (in which case we should specify 
it), or there isn't (in which case we could remove requirements).

BR, Julian