Re: #375: Most Conservative (caching and date parsing)

Dear Poul,

2012/7/16 Poul-Henning Kamp <phk@phk.freebsd.dk>:
> In message <CAMeZVwscuX986t9KMD0eXou-fgHUG8DBBkx2++AbJAt0gDs+Ng@mail.gmail.com>
> , Yutaka OIWA writes:
>
>>>> If an HTTP header field 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 does "most conservative" mean?
>
>
>>My personal proposal is instead of adding any examples, state it like "it may be
>>converted to GMT using whatever methods they think appropriate",
>
> As a time-geek, I would caution against that, because names of timezones
> are politically chosen and both their definition and naming is highly
> fragile in various parts of the world.

Yes, that's why I am proposing to remove any clauses that
morally require people to parse wrong dates "correctly".
I think my proposal is along with, not against your suggested direction.
# The original text requests people to parse these appropriately and
conservatively.

> Given that it is a class-A fuckup to send wrong dates, I will advocate
> that such timestamps SHOULD be ignored, but CAN be interpreted on a
> best-effort basis.

+1 on default to ignore.  That's one step further beyond my proposal and
it makes sense.
But I am not sure, are there any HTTP date-related headers for which
ignoring is more dangerous than guessing?

> Ohh, and also:  GMT is (maybe!) what parliament decides in the UK, the
> correct "independent" timescale is called UTC.

This is very historic :-)  In HTTP, GMT *is* the mnemonic for the Universal
Coordinated Time, independent from any local time standards of UK.

-- 
Yutaka OIWA, Ph.D.              Leader, Software Reliability Research Group
                             Research Institute for Secure Systems (RISEC)
   National Institute of Advanced Industrial Science and Technology (AIST)
                     Mail addresses: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

Received on Monday, 16 July 2012 14:59:40 UTC