Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Feedback sought on timezone headers for HTTP
749 views
Skip to first unread message
Matthew Fenelon
Oct 18, 2011, 11:29:13 AM10/18/11
to dev-pl...@lists.mozilla.org
Hi,
I'm considering putting together an Internet-Draft for adding timezone
headers to HTTP, with an eye on eventually making it to RFC. As user-agent
support is crucial to the adoption of the headers I'd like to get some
feedback on the header from user-agent developers.
Currently, to display dates and times in a user's local timezone, websites
can apply two solutions. By using a user's IP address a guess can be made as
to the user's location and thus their timezone. This mechanism breaks down
when sites are accessed through intermediary servers. It also requires each
server to implement a guessing mechanism. Another 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 updated manually when system's are
accessed from different timezones.
What I would be proposing is to have a request HTTP header
'Accept-Timezone', the value of which would consist of a set of TZIDs
(timezone identifiers) from the Olson database, in a format similar to the
Accept-Language header, a set of values with quality signifies to signify
preference. Support in user-agents would consist of; a user interface to
allow a user to select their preferred timezone(s); and to add the header to
each request. A default value could be taken from the system's timezone. An
example of the header,
Accept-Timezone: Europe/London, Etc/UTC;q=0.5
which would be read as "I prefer 'London, UK' time, but will accept UTC".
There is a second header, 'Content-Timezone' that would be used by servers
to signal that a response was 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.
It'd be great if I could get someone to help me by answering some questions
I have:
* Any feedback on the headers would be appreciated.
* Does this seem like a feature that Mozilla would be interested in adding
support for, if the headers made it to RFC status?
* What would be the best way of getting support added?
Thanks in advance,
Matt
I'm considering putting together an Internet-Draft for adding timezone
headers to HTTP, with an eye on eventually making it to RFC. As user-agent
support is crucial to the adoption of the headers I'd like to get some
feedback on the header from user-agent developers.
Currently, to display dates and times in a user's local timezone, websites
can apply two solutions. By using a user's IP address a guess can be made as
to the user's location and thus their timezone. This mechanism breaks down
when sites are accessed through intermediary servers. It also requires each
server to implement a guessing mechanism. Another 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 updated manually when system's are
accessed from different timezones.
What I would be proposing is to have a request HTTP header
'Accept-Timezone', the value of which would consist of a set of TZIDs
(timezone identifiers) from the Olson database, in a format similar to the
Accept-Language header, a set of values with quality signifies to signify
preference. Support in user-agents would consist of; a user interface to
allow a user to select their preferred timezone(s); and to add the header to
each request. A default value could be taken from the system's timezone. An
example of the header,
Accept-Timezone: Europe/London, Etc/UTC;q=0.5
which would be read as "I prefer 'London, UK' time, but will accept UTC".
There is a second header, 'Content-Timezone' that would be used by servers
to signal that a response was 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.
It'd be great if I could get someone to help me by answering some questions
I have:
* Any feedback on the headers would be appreciated.
* Does this seem like a feature that Mozilla would be interested in adding
support for, if the headers made it to RFC status?
* What would be the best way of getting support added?
Thanks in advance,
Matt
Justin Wood (Callek)
Oct 18, 2011, 6:48:17 PM10/18/11
to
make the call on implementation for Mozilla. but my opinion is that HTTP
is the absolute wrong medium for this data exchange.
Having web browsers silently pass my Timezone along to every website
would, imo, be a privacy concern. You can use geolocation API to get TZ
specific info from a user if they allow your website to know it. You can
also just use Date.time to "guess" their timezone from a few available
sources.
While I personally would never really mind my TZ info being available to
websites, (I never hide it online), I can see cause for privacy concern
from others.
--
~Justin Wood (Callek)
Henri Sivonen
Oct 19, 2011, 6:58:42 AM10/19/11
to dev-pl...@lists.mozilla.org
On Tue, Oct 18, 2011 at 6:29 PM, Matthew Fenelon
<matthew...@gmail.com> wrote:
> Currently, to display dates and times in a user's local timezone, websites
> can apply two solutions. By using a user's IP address a guess can be made as
> to the user's location and thus their timezone. This mechanism breaks down
> when sites are accessed through intermediary servers. It also requires each
> server to implement a guessing mechanism. Another 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 updated manually when system's are
> accessed from different timezones.
Third: Query the time zone using JavaScript.
<matthew...@gmail.com> wrote:
> Currently, to display dates and times in a user's local timezone, websites
> can apply two solutions. By using a user's IP address a guess can be made as
> to the user's location and thus their timezone. This mechanism breaks down
> when sites are accessed through intermediary servers. It also requires each
> server to implement a guessing mechanism. Another 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 updated manually when system's are
> accessed from different timezones.
> Accept-Timezone: Europe/London, Etc/UTC;q=0.5
I think this header shouldn't be supported by Firefox. If you consider
how often the information would be used relative to the number of
total HTTP requests made, the information isn't needed anywhere near
every request. I think we, therefore, shouldn't bloat HTTP requests
with this header.
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Zack Weinberg
Oct 19, 2011, 1:09:55 PM10/19/11
to
On 2011-10-18 8:29 AM, Matthew Fenelon wrote:
> Currently, to display dates and times in a user's local timezone, websites
> can apply two solutions. By using a user's IP address a guess can be made as
> to the user's location and thus their timezone. This mechanism breaks down
> when sites are accessed through intermediary servers. It also requires each
> server to implement a guessing mechanism. Another 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 updated manually when system's are
> accessed from different timezones.
It seems to me that your goals would be better served by adding
> Currently, to display dates and times in a user's local timezone, websites
> can apply two solutions. By using a user's IP address a guess can be made as
> to the user's location and thus their timezone. This mechanism breaks down
> when sites are accessed through intermediary servers. It also requires each
> server to implement a guessing mechanism. Another 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 updated manually when system's are
> accessed from different timezones.
timezone-adjustment logic to the HTML5 <time> element. If the browser sees
<time datetime="2011-10-19T10:02:31-07:00"
format="%A, %B %e, %Y at %H:%M %p"
>Wednesday, October 19, 2001 at 10:02 AM</time>
it has all the information it needs to correct the visible date to the
user's time zone. No server-side processing or new HTTP headers
required. You would have to get the @format attribute added to HTML5; I
think that's the biggest missing piece.
zw
Gervase Markham
Oct 24, 2011, 5:11:32 AM10/24/11
to
On 18/10/11 16:29, Matthew Fenelon wrote:
> Accept-Timezone: Europe/London, Etc/UTC;q=0.5
You are suggesting that this be sent on every HTTP request? Is that correct?
I think you will have an enormous uphill struggle. Browsers are very
keen to avoid bloating their HTTP requests, due to concerns such as TCP
window size and so on, which can lead to a non-linear detrimental
performance impact when you get over certain sizes. The existing headers
are optimized as much as possible, and often reviewed.
If you multiply 46 bytes (the line above) up by the number of HTTP
requests issued across the web every day (billions? trillions?), you can
imagine how much more data transfer this proposal would require.
Gerv
> Accept-Timezone: Europe/London, Etc/UTC;q=0.5
You are suggesting that this be sent on every HTTP request? Is that correct?
I think you will have an enormous uphill struggle. Browsers are very
keen to avoid bloating their HTTP requests, due to concerns such as TCP
window size and so on, which can lead to a non-linear detrimental
performance impact when you get over certain sizes. The existing headers
are optimized as much as possible, and often reviewed.
If you multiply 46 bytes (the line above) up by the number of HTTP
requests issued across the web every day (billions? trillions?), you can
imagine how much more data transfer this proposal would require.
Gerv
0 new messages