Monday, May 5. 2008
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
I like the javascript solution. Generally it seems that most people set their timezone correctly.
JavaScript really seems to be the most useful option here. Pre-setting a time zone is a pure convenience feature which users without javascript are expecting not to have.
It's highly unlikely that people have set their time zone incorrectly. Just think of what applications depend on correctly set time zones... Email, Calendars...
Also, if you compare the user's time with the time on your server, you can at least read an absolute GMT offset. As you don't know the actual time zone, you won't be able to say when DST begins and ends, but at least you know a sensible offset.
While it's unlikely that a user has set their timezone incorrectly, it seems inconceivable to me that they set their clock to a wrong time because that would be immediately noticeable.
While geotagging sometimes fails in a way of reporting false information, using JavaScript either fails completely, or succeeds with high probability.
I'm a proponent of failing hard, as such errors are always detectable.
Philip
It's highly unlikely that people have set their time zone incorrectly. Just think of what applications depend on correctly set time zones... Email, Calendars...
Also, if you compare the user's time with the time on your server, you can at least read an absolute GMT offset. As you don't know the actual time zone, you won't be able to say when DST begins and ends, but at least you know a sensible offset.
While it's unlikely that a user has set their timezone incorrectly, it seems inconceivable to me that they set their clock to a wrong time because that would be immediately noticeable.
While geotagging sometimes fails in a way of reporting false information, using JavaScript either fails completely, or succeeds with high probability.
I'm a proponent of failing hard, as such errors are always detectable.
Philip
User's settings are definetely much more reliable than IP to timezone mapping. That's obvious. Not mentioning that, it's less resource-consuming solution. The only problem is when someone has JS disabled, but then, just like Philip said, it's detectable.
Btw, sometimes I've seen someone was using IP to detect user language, while it can be easily read from ACCEPT_LANGUAGE header, not even JS needed.
I think user settings are always much more trustworthy than IP. Straight and simple (KISS!).
Btw, sometimes I've seen someone was using IP to detect user language, while it can be easily read from ACCEPT_LANGUAGE header, not even JS needed.
I think user settings are always much more trustworthy than IP. Straight and simple (KISS!).
oh yes... I hate sites which do language detection based on geoip data.
You see: I live in Switzerland, but I'm very fluent in english and I always prefer the original english content than some (usually not really great) translation.
That's why I've configured my browser to send Accept-Language: en.
I hate sites trying to be intelligent and present me with a german interface none the less - besides: Here in Switzerland, some speak german, some french and some italian. Defaulting to german isn't that intelligent in our case.
The issue I DO have with accept-language is though that it's very difficult to set up. At least for novices it is.
While it's easy (and often done automatically) to set the correct time, actually going into the browsers settings screen to tweak a knob you don't really know what it does and which has non-obvious effects is much, much harder.
This is why language detection via used domain (mysite.de as opposed to mysite.com for example) or by just providing a language selection usually works better.
Philip
PS: Sorry for taking over your blog for this not-really-related topic, Jonathan.
You see: I live in Switzerland, but I'm very fluent in english and I always prefer the original english content than some (usually not really great) translation.
That's why I've configured my browser to send Accept-Language: en.
I hate sites trying to be intelligent and present me with a german interface none the less - besides: Here in Switzerland, some speak german, some french and some italian. Defaulting to german isn't that intelligent in our case.
The issue I DO have with accept-language is though that it's very difficult to set up. At least for novices it is.
While it's easy (and often done automatically) to set the correct time, actually going into the browsers settings screen to tweak a knob you don't really know what it does and which has non-obvious effects is much, much harder.
This is why language detection via used domain (mysite.de as opposed to mysite.com for example) or by just providing a language selection usually works better.
Philip
PS: Sorry for taking over your blog for this not-really-related topic, Jonathan.
Actually language detection should be always just additional feature (for a start site for example). No doubt, websites should allow to easily change language to whatever you want (your choice can be even remembered in cookies for future visits).
The article (by D.Rethans) that Jonathan mentions below is definetely worth reading. It shows difference between determining UTC offset and actual timezone.
The article (by D.Rethans) that Jonathan mentions below is definetely worth reading. It shows difference between determining UTC offset and actual timezone.
@Philip: It is all partially related. I've no issues with the current focus of the conversation.
That being said, Derick Rethans has a interesting follow up which is definitely worth a read . . .
"Through Planet PHP I found an article on Pre-populating forms with the timezone. I'd normally add a comment instead, but the comment would almost be larger then the original post, so I am instead writing up an entry myself. The post describes several ways to obtain the user's timezone and use that to pre-fill a form. None of them are working properly though. I'll try to explain for each of them why not, but first of all it is important to know what a timezone actually is."
http://derickrethans.nl/detecting_timezone_by_ip.php
That being said, Derick Rethans has a interesting follow up which is definitely worth a read . . .
"Through Planet PHP I found an article on Pre-populating forms with the timezone. I'd normally add a comment instead, but the comment would almost be larger then the original post, so I am instead writing up an entry myself. The post describes several ways to obtain the user's timezone and use that to pre-fill a form. None of them are working properly though. I'll try to explain for each of them why not, but first of all it is important to know what a timezone actually is."
http://derickrethans.nl/detecting_timezone_by_ip.php
If you use PHP, there is a PHP module you can enable called GEOIP. This will also get you the name of the city and state of an IP. Very useful.
@Skip
Thanks, Indeed, that IP address lookup and geotargeting information tool is very useful. Haven't heard of it before.
Thanks, Indeed, that IP address lookup and geotargeting information tool is very useful. Haven't heard of it before.
#5.1
on
2008-07-28 02:26
If you want the local time and you have either the IP Address or the lat/long coordinates, why not just use the local time api from world time engine?
http://worldtimeengine.com/api
http://worldtimeengine.com/api/ip
http://worldtimeengine.com/api
http://worldtimeengine.com/api/ip
#6
on
2008-07-14 19:53
Will give max mind and the world time engine a try 

#7
on
2009-04-06 06:54
Thanks so much for sharing this with us. I'm sure it will be quite useful.
#8
on
2009-04-09 00:50
The author does not allow comments to this entry