Behdad Esfahbod's daily notes on GNOME, Pango, Fedora, Persian Computing, Bob Dylan, and Dan Bern!

My Photo
Name:
Location: Toronto, Ontario, Canada

Ask Google.

Contact info
Google
Hacker Emblem Become a Friend of GNOME I Power Blogger
follow me on Twitter
Archives
July 2003
August 2003
October 2003
November 2003
December 2003
March 2004
April 2004
May 2004
July 2004
August 2004
September 2004
November 2004
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
July 2008
August 2008
October 2008
November 2008
December 2008
January 2009
March 2009
April 2009
May 2009
June 2009
July 2009
August 2009
November 2009
December 2009
March 2010
April 2010
May 2010
June 2010
July 2010
October 2010
November 2010
April 2011
May 2011
August 2011
September 2011
October 2011
November 2011
November 2012
June 2013
January 2014
May 2015
Current Posts
McEs, A Hacker Life
Monday, October 27, 2008
 Timezone in HTTP Header

[I have been thinking about this problem in the back of my head for the past few months. A Lazyweb request is in order.]

Dear Lazyweb:

Web services are used from all over the globe. How is it that the HTTP request does not include the timezone the request is coming from?

Context: A few years ago I wrote a multi-system calendar widget in PHP, called Behdad Calendar. It has many Iranians users in and out of Iran. Since the service is run on my web server somewhere in the western world, most Iranians in Iran see the date wrong for about one-third of the day.

My first response to this was "cool, I just need to adjust to the user's timezone which I can easily find somewhere in the HTTP request". Then I failed to find that. Then I noticed the stupid pattern: any complex-enough web application asks me to enter my timezone. Something my browser perfectly knows already.

So, why is that? How to fix it? Is there anything I've been missing?

[Before someone mentions, yes, some hosting companies will start blocking out Iranian users based on their uniquely distinct +3:30 timezone. Then again, Iranians are used to using anonymizers to work around various filters, originated in Iran or out.]

Labels: , , ,

Comments:
Time zones are complicated. It is pretty easy to determine the user's current UTC offset, since you can use javascript to find out the current date/time in local time and compare that against UTC.

If all you want to do is display the current date, you're done. But if you want to display past or future dates, this is not enough.

The country the user is from might observe daylight savings. Depending on which hemisphere they're in, this will be at a different time of year, and there aren't even standardised start/finish times within one hemisphere. The daylight savings rules might not be consistent from year to year.

So for something like a calendar application, you definitely need more information than a UTC offset. You can make an educated guess based on the offset and GeoIP data, but if you want things to be accurate, you'll need to ask the user (you might offer a limited selection based on the observed offset and GeoIP data though).
 
JavaScript can provide all necessary details, including both UTC offset and DST behavior.

That is, unfortunately, the only way to get the info from the client.

It isn't necessary to get the settings from the client in all cases, though. You might be perfectly happy with just spitting out dates in UTC and adding a bit of JavaScript to the page to convert all those dates into local times.

If you spit out the dates in a standard format and always wrap them in a span tag with a specific class, it's pretty easy to do with jQuery (or any other JavaScript toolkit).
 
There's a (just-recently-expired) internet draft proposing a client header for this: http://tools.ietf.org/html/draft-sharhalakis-httptz-04.

I don't think it has gotten much discussion though.
 
sean: Javascript dates are not historically correct, at least in IE. It always calculates according to current effective rules, which can lead to errors if DST rules changed in the mean time.

I use icu library on the server to get correct dates in all cases.
 
Anon, the reason that Javascript in IE sucks in because Windows doesn't do timezoning correctly. Windows only knows the current effective rules, and doesn't store the past rules in the registry.

Why do you think that they have such terrible trouble with their calendaring software every time a government changes their DST?

I also wonder why Israel changed their way of doing DST. I've always harboured a suspicion it wasn't due to a need for a common standard, but was because Windows just couldn't handle it.

</conspiracy>
 
Hi Behdad,

Multi-region/Multi-timezone web service consuming applications are a problem dear to my heart.

Unfortunately the best workaround I could get to was an ugly hack:
Always serialize dates as strings, and always transport (and store and process) dates as UTC time. Then simply leave it up to the client to deserialize the date as UTC and convert it to their local timezone.

Not a direct answer to your question, but hopefully still usefull.

jba
 
Storing dates in UTC might not be correct. For example, I schedule a meeting for April 4 2009, 3pm local time. If the DST rules change in the mean time, converting back from UTC might give you 2pm or 4pm!
 
Post a Comment



<< Archive
<< Home