Subject: Feedback sought on timezone header for HTTP

From: Matthew Fenelon <[email-masked]>
Date: Tue, 6 Dec 2011 17:14:47 +0000

Hi,

I'm considering putting together an Internet-Draft for adding timezone headers to HTTP and I'd like to elicit feedback from yourselves (the HTTPWG) before I go any further.

There has been previous discussion about adding support for timezones to HTTP, e.g. http://tools.ietf.org/html/draft-sharhalakis-httptz. The last update to that draft was (almost) two years ago. I have been in contact with the author of that draft. I'm still waiting for feedback. The feedback to that draft on this mailing list was mostly positive.

Currently to display dates and times in a user's local timezone websites can apply two solutions. A user's timezone can be guessed by their location using the requesting client IP address. This does not account for user's who wish to have a timezone different to their current locations timezone. This mechanism breaks down when sites are accessed through intermediary servers. It also requires each server to implement their own guessing mechanism. The other way is to manually ask the user what timezone they would prefer and save their choice. This solution is laborious for the user and it must be manually updated by the user if they change timezones.

What I would be proposing is to have a request HTTP header 'Accept-Timezone' that would obsolete the need for the approaches detailed above. The value of the header would consist of a timezone identifier from the Olson database. An example of the header,

Accept-Timezone: Europe/London

A response header, 'Content-Timezone' would be used by servers to signal that a response's content had been modified for a particular timezone. An example of this header,

Content-Timezone: Europe/London

which would signal that the response was modified for the 'London, UK' timezone.

As this will lead to different content being returned for a URI I would stipulate in the draft that the Vary header should be used if the response has been modified for a particular timezone. Clients or intermediaries that understand the Content-Timezone header would use that value instead of Vary. An example:

Vary: Accept-Timezone

I believe a timezone identifier would be useful to more applications than just an offset from UTC as it allows for historical and future date/times to be converted accurately to a client's timezone.

* If I raised an I-D does it seem likely that this would be something that the HTTPWG would endorse? I believe this is required to get past draft status.
* I believe Vary would be enough to enable intermediaries/clients to differentiate between different responses. Is this correct?
* Any other feedback would be appreciated.

Thanks in advance,

Matt Fenelon

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Dec 2011 19:38:57 +0100

On 2011-12-06 18:14, Matthew Fenelon wrote:
> ...

Did you have a look at HTML5's <time> element?

Best regards, Julian

---

From: Karl Dubost <[email-masked]>
Date: Thu, 8 Dec 2011 14:47:50 -0500

> Accept-Timezone: Europe/London

One potential issue I can imagine. As soon as something releases 
explicit information about location, people use it. I can see Web 
developers (and marketers) being happy about this one. Not used 
for time, but for location data mining and send a representation 
which is geolocated in addition to the commons geoip dbs. 

It also increases the Web fingerprinting surface of someone.

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software

---

From: David Morris <[email-masked]>
Date: Thu, 8 Dec 2011 13:24:36 -0800 (PST)

On Thu, 8 Dec 2011, Karl Dubost wrote:

> > What I would be proposing is to have a request HTTP header
> > 'Accept-Timezone' that would obsolete the need for the approaches
> > detailed above. The value of the header would consist of a timezone
> > identifier from the Olson database. An example of the header,
> > 

I'm not convinced that the web fingerprinting exposure is much different
than what is already available via the date: GMT Offset, IP, etc. Easy to
mitigate by requiring user opt-in for sending the information and/or
sending explicit wrong information.

I also see minimal value in adding this complexity vs. just using the
GMT offset in conjunction with accept values.

With the current shared profiles supported by facebook, google, et al,
I think the equivalent functionality is available and more obviously
configurable from the user's perspective.

Dave Morris

---

From: Julian Reschke <[email-masked]>
Date: Thu, 08 Dec 2011 22:32:17 +0100

> GMT offset in conjunction with accept values.

Are you referring to the Date: header field?

"All HTTP date/time stamps MUST be represented in Greenwich Mean Time 
(GMT), without exception. For the purposes of HTTP, GMT is exactly equal 
to UTC (Coordinated Universal Time). This is indicated in the first two 
formats by the inclusion of "GMT" as the three-letter abbreviation for 
time zone, and MUST be assumed when reading the asctime format." -- 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-17.html#http.date>

Best regards, Julian

---

From: David Morris <[email-masked]>
Date: Thu, 8 Dec 2011 13:46:25 -0800 (PST)

Ooops ... blush ... not only did my memory of the date header format fail,
I forgot that it isn't a common part of the request.

I still prefer that the information be part of the application and not
default data provided by the browser.

On Thu, 8 Dec 2011, Julian Reschke wrote:

> "All HTTP date/time stamps MUST be represented in Greenwich Mean Time (GMT),
> without exception. For the purposes of HTTP, GMT is exactly equal to UTC
> (Coordinated Universal Time). This is indicated in the first two formats by
> the inclusion of "GMT" as the three-letter abbreviation for time zone, and
> MUST be assumed when reading the asctime format." --

---

From: Julian Reschke <[email-masked]>
Date: Thu, 08 Dec 2011 23:02:02 +0100

> default data provided by the browser.

Absolutely.

The intent of the HTML <time> element was to do just that; send a 
non-localized value, and allow the UA to reformat.

Best regards, Julian

---

From: Matthew Fenelon <[email-masked]>
Date: Tue, 13 Dec 2011 11:28:56 +0000

> -----Original Message-----
> From: Julian Reschke [mailto:[email-masked]]
> Sent: 06 December 2011 18:39
> 

I wanted to use the header with a HTTP API that uses XML and JSON as content-types. However I see your point about adding the complexity to the content type rather than to the HTTP protocol itself. Thanks for your feedback.