09/06/08 Global Services Thinking Local

CHICAGO, UNITED STATES - Excluding the language barrier, the internet is the most global form of communication possible. It always shocks me how services think local. Twitter is an example of how many US websites rate international users as 2nd class. They are sending the message that they don’t care as much about the 60% of us who live outside their borders.
When I change my timezone (see screenshot above) they have pulled out all the US timezones out of alphabetical order and put them at the top to help people. Of course I couldn’t find it in the alphabetical list and not believing it had to set my timezone in Chicago to somewhere in Mexico as a stop-gap. I’m all for prefixing a ‘Top 10 Destinations’ list at the top of a select field, but you can’t just single out a country because you live there - it shows a complete lack of global thinking.
I’m a fool to this myself. While I thought of global languages - I didn’t think of global timezones before starting ‘decisions for heroes’. I now need to recode the ability for users to offset themselves. I’m making a presumption that everything would be stored in the database as GMT+0 and then user profiles offset the time for display and vice versa for storing. Any suggestions on how to handle different local daylight saving standards?
-Robin.
Tags: coding, decisions for heroes, timezones, twitter
3 Comments
I’ve had the same issue of offsetting user data based on their current timezone.
Here’s what I used as a solution:
When a user creates their account they select their preferred timezone.
Then every time they login I set the ‘TZ’ environment variable in PHP to the timezone they selected. This correctly offsets their timestamps against the server’s, which is currently set to GMT+1.
So as a quick example, say the user is in Hawaii and signs up for a new account. They select ‘(GMT-10:00) Hawaii’ from the selection of timezones. This text then corresponds to the correct TZ syntax for that timezone, which in this case is ‘Pacific/Honolulu’.
The environment variable for the current timezone in PHP can then be set using the built in putenv() php function.
And that’s it. Now every time a user does something to cause a timestamp record to be saved, it’s correctly offset based on what they provided when they created their account.
To make things simpler for myself, when a user logs in I pull out their preferred timezone and pop it into a session variable, so that I can use it to set the timezone on each subsequent page without querying the database any further.
Here’s what I use for that:
putenv("TZ=".$_SESSION['user']['timezone']);
Hope this helps!
Nice one. So I would have presumed everything in the DB should be stored in the same timezone so it’s sortable, no?
Hmmm, good point.
I haven’t yet done any extensive testing in sorting data created by users in different timezones. Dammit. it’s now top of the list!
I can think of a few alternatives but they’re a little over complicated. I’ll do some further testing on this and get back to you.
![Robin Blandford [ ByteSurgery.com ]](http://www.bytesurgery.com/blog/wp-content/themes/starkers/images/blank.gif)
