Monday, May 5. 2008
Pre-populating forms with the timezone
Following my initial discussion on using geo-targeting to predict timezones I've finally found time to play around with some of these ideas.
The idea
Simplify the user experience by predicting the timezone someone is in and auto-populating a registration form accordingly.
The solution
At the time I wasn't really looking for any solutions other than matching an IP address up to an actual location. This is certainly possible and I'll show you how below but first I'll highlight the alternative. If you are reasonably confident that the timezone will be set correctly on the users computer it is possible to access that value via javascript.
GeoIP to Timezone
If you want to avoid relying on javascript then you still have some options.
Maxmind: The PEAR pacakage supporting maxminds geoip databases doesn't support timezone lookup but the script offered by maxmind directly does support timezone lookup. The usage seems a little convoluted but it is there.
IP2Location: The timezone information is integrated directly in the database once you reach 'DB11', their 11th database offering. The usage should be straightforward. There is only one drawback - DB11 costs $649/year. Personally this is more than I would be willing to spend but their client list is impressive so if this is within your budget spread the moolah and use my affiliate link
.
Free solution: There are still a few options here. Although I haven't tried it I believe the maxmind code should work with their GeoLite products. Alternatively once you have a location, either using maxminds free databases or hostip.info you could try getting to a timezone using the 'world time engine' class available from phpclasses.org. The drawback with this approach is that even after the database lookup you still need to query two web services. That is going to introduce a significant lack in response time.
My preference
Although I started off looking at GeoIP services I would much prefer to be able to tackle this problem using javascript. It's not an ideal solution, some people will have their timezone set incorrectly while others will have javascript disabled but on balance I think it is good enough. This is the icing on the cake rather than core functionality after all.
The idea
Simplify the user experience by predicting the timezone someone is in and auto-populating a registration form accordingly.
The solution
At the time I wasn't really looking for any solutions other than matching an IP address up to an actual location. This is certainly possible and I'll show you how below but first I'll highlight the alternative. If you are reasonably confident that the timezone will be set correctly on the users computer it is possible to access that value via javascript.
GeoIP to Timezone
If you want to avoid relying on javascript then you still have some options.
Maxmind: The PEAR pacakage supporting maxminds geoip databases doesn't support timezone lookup but the script offered by maxmind directly does support timezone lookup. The usage seems a little convoluted but it is there.
IP2Location: The timezone information is integrated directly in the database once you reach 'DB11', their 11th database offering. The usage should be straightforward. There is only one drawback - DB11 costs $649/year. Personally this is more than I would be willing to spend but their client list is impressive so if this is within your budget spread the moolah and use my affiliate link
.Free solution: There are still a few options here. Although I haven't tried it I believe the maxmind code should work with their GeoLite products. Alternatively once you have a location, either using maxminds free databases or hostip.info you could try getting to a timezone using the 'world time engine' class available from phpclasses.org. The drawback with this approach is that even after the database lookup you still need to query two web services. That is going to introduce a significant lack in response time.
My preference
Although I started off looking at GeoIP services I would much prefer to be able to tackle this problem using javascript. It's not an ideal solution, some people will have their timezone set incorrectly while others will have javascript disabled but on balance I think it is good enough. This is the icing on the cake rather than core functionality after all.
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
