> Isn't it more of a matter of conflict between the RFC for net
> messages (822?), which requires that funky
> dow, dm mon yy hh:mm:ss zone
> date/time format with a 2 digit year (dow of week, 2 digit day of month,
> etc.), instead of the ISO (1685?) form
> year-mm-ddThh:mm:ss
> Sorry about vagueness on the standard designation numbers, but
> I don't have a way to pop over to check them from here, and pop
> back to continue to compose the message. The RFC is linked in
> with the http://www.apache.org documentation pages.
Hmm, the link on the Apache pages refers for date formats to RFC 850,
which is an obsolete standard for USENET message transport. (The
current standard is RFC 1036, as far as I know, though there have been
some changes over the last ten years.) Both of them inherit the Date
format from RFC 822 (the email standard), which allows but does not
require a four-digit year. There might be some confusion because both
give an example of a two-digit-year date which is acceptable and a
four-year-digit date which is not, but the length of the year field is
not the problem.
The version of the HTTP/1.0 spec which is RFC 1945 specifies that there
are three acceptable date formats:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
The first two are subsets of the formats allowed by the referenced
RFCs. The first format is preferred; the third format is supposed
to be accepted but never generated (a legacy format).
The spec has at various times said slightly other things, so not all
implementations generate exactly these dates (Apache 1.0.0, at least,
puts a "?" for the time field, provision for which was IIRC in the spec
at one point but seems to be no longer.)
Anyway, the upshot of all this is that HTTP is not Y2K-incapable,
although one of the three allowable date formats will become unusable.
(I do wonder about Year 10000 compliance --- there will be a *lot* of
legacy code by then.)
--
PGP 0x27F772C1: 0C 0D 10 D5 FC 73 D1 35 26 46 42 9E DC 6E 0A 88
USENET: No Fun Anymore since 1987
by