We built basically the exact same library at foursquare (though it's in Scala not Java). Would anyone be interested in using it if we open sourced it? We probably should.
I am the developer. Regarding price, we decided to start charging because the serving costs were non trvial and I had been getting a lot of email requests for support that were taking up my time. Then Google App Engine prices went up too.<p>We didn't expect many paying subscribers and that is how it turned out, but we have enough to make it worth leaving the site up and running.<p>For low volume users we are thinking of offering a pay-go pricing option AWS style, with a low per-query price.<p>But this is not our main project now (WeatherSpark.com is) so I don't know when we'll get around to making changes.
I don't understand why this has to be queried against a server. Time zones don't change that much. Why can't this just be a standalone library download?
I've been using AskGeo for about 10 months and am very happy with it. Does exactly what I need. I am surprised to see it's now $200/year.<p>What I signed up AskGeo said:<p>Is this free?<p><pre><code> Yes, for now. We built this for internal use and this site doesn't cost
us much, so we don't intend to charge unless usage takes off. If we do
charge, it will be to cover costs, not because we think we're going to
make it big selling access to a lat/lon to time zone API. So for now it
is free and it is likely to remain so for a long while.
</code></pre>
The pricing change has not been communicated to existing users, I was not aware of it until this story had been posted. I'm not sure if they get grandfathered or not. I'm doing about 1 request a day, $200 seems expensive.
You could implement your own using the shapefiles from <a href="http://efele.net/maps/tz/world/" rel="nofollow">http://efele.net/maps/tz/world/</a>. They have derived the shape files from fip10s data which itself is derived from VMAP0 data.<p>We created a rough implementation similar to this at postmates using this information but didn't find it worthy of open sourcing.
Looks useful - something that my company could use at any rate. We're currently a customer of geonames's commercial web service.<p>I have a few recommendations for the developer:<p>First, the GMail account restriction sounds odd. But I'm guessing you can sign up with any Google account? Lots of people have Google accounts, but don't use GMail... If you can sign up with a Google account (like you often can with app-engine apps), I'd suggest calling it a Google account, not a GMail account.<p>Second, I think the one-price-for-all-commercial-use is off-putting. I've already seen a light user talking about the price being expensive for 1 request a day, which perhaps it is, and you suggested that commercial users with low usage requirements should contact you. Generally speaking I think you want to be making custom deals for the heavy users, not the light ones. If you want to cater for the light commercial users, you might do better to offer an off-the-shelf package that will appeal to them (whilst being too restrictive for the customers that want heavier usage).<p>I think heavy users would often a) be willing to pay more than $200 a year (which is under $17 a month i.e. very little), and b) be concerned about the fixed price because you wouldn't be able to sustain heavy usage at that low price and so the chances are that you'd want to cut them off for making too many requests. That's a lose lose situation, when it could easily be a win win (them as a happy heavy customer and you getting more money).<p>I suspect some sort of rate-limit-based subscription pricing or credit-based pay-as-you-go system may be the way forward. If you used a service like FastSpring you could be taking subscription payments very quickly. (I recommend FastSpring because we're using them and I think they're great.)<p>I don't want to imply that I know what pricing would make most sense for you - I don't - but I'm pretty confident that the current pricing is a long way from optimal.
I've been using GeoNames for this functionality to allow users to auto-fill their location & timezone using geolocation for browsers that support it.<p>Their API endpoint is at <a href="http://ws.geonames.org/timezoneJSON?lat=&lng=" rel="nofollow">http://ws.geonames.org/timezoneJSON?lat=&lng=</a><p>I've been using it for so long that I don't even know where their docs are anymore.
Amusingly, I had to implement this not 2 days ago. Since we're using MaxMind's GeoIP lookup anyway, it was just a case of using the auto-generated com.maxmind.geoip.timeZone class.<p>Edit: Not quite lat / long to Time Zone, though, more IP -> Location -> Time Zone.
This is very easily done with a mesh of two APIs, see <a href="https://bitbucket.org/tebeka/pythonwise/src/tip/timeat" rel="nofollow">https://bitbucket.org/tebeka/pythonwise/src/tip/timeat</a>
To play devil's advocate, why is a service like this even necessary anymore?<p>You don't need a users GeoLocation to find out what timezone they are in. In a web page this information is already available in javascript:<p><a href="http://www.w3schools.com/jsref/jsref_getTimezoneOffset.asp" rel="nofollow">http://www.w3schools.com/jsref/jsref_getTimezoneOffset.asp</a><p>On the server and your DB you should always store UTC, and your server app should avoid localization if possible, and move all Date-to-String conversion to the client. Then all this timezone nonsense completely disappears.