- From: Yutaka OIWA <y.oiwa@aist.go.jp>
- Date: Mon, 16 Jul 2012 22:47:15 +0900
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Dear Mark and Amos, 2012/7/16 Mark Nottingham <mnot@mnot.net>: > <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/375> > >> 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? > > "Earliest" makes sense for Expires and Date, but Last-Modified it would seem that "latest" is the most conservative. For Expires, I agree. For the latter two cases it seems to be depending on further application contexts. Also, I argue how to determine possible choices from which the "conservative" one is chosen. If some implementers are willing to follow the "must be" request, should they have tables of all possible time-zone conversions and conflicts like below? CST: American Central Standard Time (-6) or China Standard Time (+8) and two more EST: American Eastern Standard Time (-5) or Australian Eastern Standard Time (+10) (much more conflicts exist) # http://www.timeanddate.com/library/abbreviations/timezones/ lists up # 4 different offsets for CST, 3 for IST, CDT and WST, and 2 for many symbols. My personal proposal is instead of adding any examples, state it like "it may be converted to GMT using whatever methods they think appropriate", emphasizing senders' responsibility for sending GMT times. This text still allows implementers to convert CST to either -5 or -6 or +8 or +9.30 according to their applications' nature or request IP address or whatever information available, or to choose the "appropriately conservative" one between -5 and +9.30. -- 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 13:48:00 UTC