Can we please get a Time-Zone: in the http request header?

If you look at an http request header, one of the lines in it is Accept-Language: de,en;q=0.7,en-us;q=0.3[CRLF]. This is telling the web server that the requester's first language preference is German (DE) and their fallback is English (EN). And if it's English, preferably the US dialect (EN-US). This info allows a website to automatically, if it supports the requested language, to present webpages in your preferred language – without the user having to do anything.

And with this language preference is handled automatically and invisibly to the user.

But when it comes to the timezone the user is in, no such luck. (For more on timezones please read What every developer should know about time).This is why you see news articles time stamped with the timezone of the server rather than your time. This is why many sites require that you select your timezone when registering. The list goes on…

I think it is way past time to add to the standard request header a line like: Time-Zone: MountainStandardTime[CRLF]. This would allow the web server to return pages with times set to the local time of the requesting browser. (The time zones can be abbreviated, but it must be done in a way to keep each unique as MST can be MountainStandardTime or MexicoStandardTime.)

Let's list out the objections to doing this, and answer them.

1. You can get the local time using GetDate() in a javascript call on the client page and returning the result. Yes you can (if the client has javascript enabled). But Arizona does not use daylight savings time so during standard time Arizona and MountainStandardTime are identical while during daylight savings time Arizona and PacificStandardTime are identical. There are other cases like this. So GetDate() does not provide a complete solution.
2. You can ask the user to set their timezone. Yes you can (and that is how most sites presently work). But news flash – people travel, and do so to different timezones. If you're like me, when you're on a trip, you leave your settings to your home timezone and do the conversion in your head. But isn't the purpose of software to make things easier for us rather than require that we adapt to the software?
3. We can't add a million new items to the http header. No we can't. But we can add a few that make sense. Bandwidth has increased substantially over the last 10 years. Adding even 10 new elements like this to the header would be immeasurably small in terms of bandwidth usage.

Now let's look at the advantages we gain from adding this functionality:

1. It will give sites that list time (news sites being the #1 case) the ability to list all times in your local time. Not just the time a news article was posted, but the times listed in the articles. When you are in Tokyo and want to watch the State of the Union address, you don't have to convert from EST – it's just listed in your local time in the article.
   This is in one respect a small thing. But I think it is important when we write code to always endeavor to make the software require as little as possible from the user and provide as much as possible. Implementing one little item like this is a small improvement. But implementing 100 little items like this, in sum, is significant. One of our jobs as developers is to find these small things and implement them.
2. Calendar programs, and not just our own but 3^rd party ones like eVite, GoToMeeting, etc., will be able to present times in the user's timezone. Where this becomes extremely useful is when appointments are set for a trip to another timezone – you can have those appointments set for that timezone and when you arrive there, you will see them in the correct local time. Without this functionality handling this gets very screwy.
3. To give a very specific example, our Arrow product (enterprise reporting & docgen system) would find this very useful when scheduling reports and displaying when reports last ran. The system runs on a server, but most of our customers have employees world-wide using it. And multiple people, many times in different timezones, are hitting the same reports. This would allow each to set events and read when reports ran in their local time – without ever having to set their timezone.

So how about it? Microsoft, Firefox, Apple, Google, Opera – it would be a piece of cake to install. Every significant operating system has the user set their local timezone. Implementing this would be a piece of cake. And it would get used – a lot.

Comments

[Justin]

A great idea, but it'd probably be best to just use standard offsets instead of named time zones:

Time-Offset: -0730
Time-Offset: +1100

etc.

[Mark Edgar]

A TIME element in HTML would let the browser display times to the user's liking and allow the server to serve static pages.

[Marcus Alanen]

@Mark Edgar: As you say, a time element sounds much better. Server stays simple, client can show whatever it wants.

There might be reasons to show time in a specific timezone regardless of the client, so I wonder if it would also make sense to say the stated usage of the time.

E.g. <time value="2010-03-04 13:00:12" usage="client" /> would be meant for the client to render as the user wishes. Other usage="..." could be invented.

Similarly, I think it would make sense to add a <money> element as well.

[Kyzer]

Justin, there is a TIME element that's currently on-track to be part of HTML 5.

[Kyzer]

http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element

[Dave Brondsema]

Some timezones are very specific to certain countries or regions, and may be exposing more information than the user wishes. E.g. Iran has their own IRST.

It will also take monumental effort to get all browsers to implement a new header. If you can use JS, why not make use of the geolocation JS API? That is gaining good traction, prompts the user before making their location available, and you can then do a location->timezone lookup. The last step might be tricky, but should be possible.

[Michael Maclean]

Justin, just sending the offset itself wouldn't be adequate, for reasons similar to what Derick Rethans outlines here: http://derickrethans.nl/storing-date-time-in-database.html

[Jeff]

I'd rather not for privacy reasons. I like the idea of a time element much more-- let the client do the work. That way the server doesn't have to know my time zone.

[anon]

Why not check the IP location?

[Matchu]

I'm confused about the point regarding travel. If we're talking about mobile devices, it makes sense. But I'd rather expect that we'd be mainly talking about laptops, which don't automatically change timezones when you travel. Right?