-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Timezone database should describe shapes not points #2
Comments
I understand your concern. Actually, our db is not just points, if you look through it, you'll find that there are ISO country names in it. So you can populate Country code and you'll get accurate result. (No matter about borders and countries shapes). Just check our wiki and algorithm. In two words, algorithm is: I not sure about US states, if you have some issues, please provide the steps to reproduce and your code. Íàä³ñëàíî ç iPhone 20 ëèñò. 2013 î 23:24 Tim Trautmann [email protected] íàïèñàâ(ëà):
|
Bringo is right. The correct way to get exact results would be a shape database, not point proximity. |
Please provide an exact example with code when the algorithm does not work correctly?
|
San Antonio, TX should be CST and is getting San Antonio - America/Shiprock (MST) offset -25200 which is incorrect. I guess database needs more precision. |
Thanks for your feedbacks, guys. We are working now on updating DB with USA states to make results more accurate for your country. |
Same issue, lack of precision. Users from 2 places had issues with local time :
But as said by everyone, implementation should use shapes instead of points, whatever the number of points you have, it will still be approximation. Also, it will be a pain if timezones shift for a reason or another in the future. |
Also I'm using country codes just in case you are wondering. Shapes is the way to go. |
I'm having the same issue as @kirualex . A user in northwestern Louisiana is having their time zone detected as EDT instead of CDT. Is there a fix or workaround? I can provide more details if it helps. |
I have a lot of problems in Indian, it seems that it doesn't support the Indian time zone. At the top, it detects the Karachi, Pakistan timezone. |
Absolutely. It is impossible to accurately do this with just points. Including country code attached to the point can't improve the precision! A nearest-neighbor approach will never work. |
There have been several people asking for 'workarounds' to this. It's not an issue that can be worked around; a time zone is not a circle, and even were it, circles don't tesselate. It's a nice idea to provide this service, but it will never work based on an algorithm using nearest-point search. |
See also this post: http://stackoverflow.com/questions/16086962/how-to-get-a-time-zone-from-a-location-using-latitude-and-longitude-coordinates APTimeZones is essentially doing the approach that is recommended not to do. (See the diagram with the two squares.) |
@mj1856 I like that APTimeZones works offline. It's just too bad about the reliability. I ended up writing a CLLocation category (see the gist) that does a reverse geocode lookup. I use this when I'm online, and fall back to APTimeZones when offline. It's not perfect, but the failure rate is much lower. |
@chriscdn Thanks for the gist. Great that CLGeocoder actually fetches time zone information. Sad it's buried so deeply. I filed a radar: http://openradar.appspot.com/21163976 (Enhancement: add CLPlacemark.timeZone) |
Here is a Swift library that uses polygons instead of points: https://github.com/drtimcooper/LatLongToTimezone |
I don't quite understand how this would accurately return the timezone. Timezones are shapes defined by government organizations. Your database describes points. Your code will not function properly near timezone borders or in cases where there are actually holes in timezone shapes like in the US state of Indiana and in parts of Arizona.
The text was updated successfully, but these errors were encountered: