David Lee wrote:
On Thu, 23 Mar 2006, Craig Morrison wrote:
At any rate and to try and bring this discussion somewhat back on topic,
strftime makes it trivial to change date formats merely by changing the
format string given as one of its arguments. Any debate regarding
difficulty of change by the vendor is mere smoke being blown into the wind.
My own reading of 2822 (especially 4.3, last paragraph about "obs-zone")
is that this specification is definitely unwise: it violates the
convention (care: not itself factual) "be conservative in what you send".
This is the crux of the situation right here.
The vendor is assuming that others will swallow their spewage and
account for it.
Further, 2822 section 3.3 has:
date-time = [ day-of-week "," ] date FWS time [CFWS]
...
time = time-of-day FWS zone
...
zone = (( "+" / "-" ) 4DIGIT) / obs-zone
Taking FWS and CFWS into consideration, this _seems_ more clearly to put
that "Date:" form the ISP in technical breach. Do we agree that such
"breach" classification is a correct, technically demonstrable,
derivation from 822 and 2822?
I didn't make myself clear earlier (and before this thread strayed
off-topic), yes, technically they are in breach of the specification.
However, if they wish to use their current format all they need do is
drop anything beyond the 3 letter time zone (e.g; 'Standard Time') and
it will bring their date-time back into spec.
That being said, it would behoove them to use ((+/-) 4DIGIT) as it
removes all ambiguity for the zone in question and that is what the
revision in RFC2822 is all about.
--
Craig
