Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

'Most conservative' conversion to GMT?

Section 19.3 "Tolerant Applications" of the HTTP 1.1 RFC (2616) says on the subject of parsing dates from HTTP client applications:

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.

Two questions:

  1. Does this mean that the server MUST convert a non-GMT date value to GMT? Or does it mean that if (optionally) it chooses to convert a non-GMT date value to GMT (rather than rejecting it) then it MUST use the most conservative possible conversion?

  2. What is meant by "the most conservative possible conversion"?

Edit Although this is now an old question, I'm still interested in knowing the answer if anyone has it.

like image 401
Ian Goldby Avatar asked Jul 12 '12 09:07

Ian Goldby


People also ask

What is AST compared to GMT?

Time zones with the GMT -4 offset: AST - Atlantic Standard Time.

How do I convert standard time to GMT?

The India Standard Time (IST) is 5.5 hours ahead of Greenwich Mean Time (GMT).

Is GMT 10 the same as AEST?

Most of Australia uses three standard time zones, Australian Eastern Standard Time (AEST) which is UTC/GMT+10, Australian Central Standard Time (ACST) which is UTC/GMT + 9 1/2 and Australian Western Time (AWST) which is UTC/GMT +8.

How do I convert GMT to local time?

(1) In above formulas, 9 is the number of hours the local time ahead to GMT, and you can change it as you need, if the local time is backward to the GMT, you just can change the plus sign + to minus sign -. (2) The formula =A2 + (9 / 24) will return a decimal number.


1 Answers

Does this mean that the server MUST convert a non-GMT date value to GMT? Or does it mean that if (optionally) it chooses to convert a non-GMT date value to GMT (rather than rejecting it) then it MUST use the most conservative possible conversion?

This is really something that's more specific to the field in question than something that's applied generally. There is a working group draft that would obselete RFC 2616 that has this to say about conversion in caches:

  • 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).
  • Although all date formats are specified to be case-sensitive, recipients SHOULD match day, week and timezone names case-insensitively.
  • An HTTP/1.1 implementation MAY internally represent a parsed Expires date as earlier than the proper value, but MUST NOT internally represent a parsed Expires date as later than the proper value.
  • All expiration-related calculations MUST be done in GMT. The local time zone MUST NOT influence the calculation or comparison of an age or expiration time.
  • Caches SHOULD consider dates with time zones other than "GMT" invalid.

What is meant by "the most conservative possible conversion"?

Under this context, it doesn't seem to mean anything specifically aside from when faced with 2 outcomes, pick the most "conservative" date based on the context of the date.

Given 2 dates that was fuzzy parsed, in the context of a Last-modified header, the most conservative would be the "later" one. But in the context of a Expires header, the earlier of the 2 is more conservative. Anything requiring a significant amount of guessing should just return an error response.

like image 152
Jon Lin Avatar answered Sep 22 '22 00:09

Jon Lin