Lat/Long to Time Zone API
askgeo.com
askgeo.com
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.
For low volume users we are thinking of offering a pay-go pricing option AWS style, with a low per-query price.
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 have an Android tablet that is wifi only and hence cannot get time details from cell towers. I use this app which corrects the time via NTP, and updates the timezone information automatically by querying geonames.
But it seems like in most cases the use case is for an app running on an appserver somewhere, in which case it makes sense to have a library I'd say.
Depends on the scale of your application. If it's truely global, then timezones change often. I think Russia tends to change it's timezones every 5 years or so
What I signed up AskGeo said:
Is this free?
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.
What do you think a reasonable fee would be?
Up to 200 calls/day for free.
This API can be used to search by coordinates, IP Addresses and place names to get the most accurate current local times for a given place.
We created a rough implementation similar to this at postmates using this information but didn't find it worthy of open sourcing.
I have a few recommendations for the developer:
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.
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).
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).
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.)
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.
And if the 4sq guy's boss lets him spend time to open-source their attempt at this, I don't expect we will. Would be a shame. I'd bet that AskGeo is way higher performance, handles all the corner cases, and would win in a commercial market. But if the 4sq management wants to spend their investor's dollars giving away engineering resources then I suppose our sales will drop off significantly even if our product is better. Hard to compete with a price tag of zero.
Their API endpoint is at http://ws.geonames.org/timezoneJSON?lat=&lng=
I've been using it for so long that I don't even know where their docs are anymore.
We also have a very fast spatial index rather than a slow SQL-GIS solution, and last time I checked, they have usage volume restrictions that are pretty limiting.
We looked into using them before building our own solution.
Edit: Not quite lat / long to Time Zone, though, more IP -> Location -> Time Zone.
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:
http://www.w3schools.com/jsref/jsref_getTimezoneOffset.asp
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.