McEs, A Hacker Life: Timezone in HTTP Header

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: calendar, http, lazyweb, web2.0

¶ 8:00 PM

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).

# posted by

James Henstridge : October 27, 2008 9:28 PM

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).

# posted by

Anonymous : October 27, 2008 11:32 PM

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.

# posted by

Anonymous : October 27, 2008 11:38 PM

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.

# posted by

Anonymous : October 28, 2008 4:17 AM

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>

# posted by

Anonymous : October 28, 2008 9:00 AM

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

# posted by

Anonymous : October 28, 2008 7:42 PM

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!

# posted by

Anonymous : October 28, 2008 8:20 PM

About Me

Twitter Updates