Timezone database should describe shapes not points about aptimezones HOT 15 OPEN

Here is a Swift library that uses polygons instead of points: https://github.com/drtimcooper/LatLongToTimezone

from aptimezones.

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:
1). Grab timezones array filtered by given Country code
2). Get closest one according to your coordinates.

I not sure about US states, if you have some issues, please provide the steps to reproduce and your code.
We'll keep timezones.db up to date.

Íàä³ñëàíî ç iPhone

20 ëèñò. 2013 î 23:24 Tim Trautmann [email protected] íàïèñàâ(ëà):

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.

—
Reply to this email directly or view it on GitHub.

from aptimezones.

Bringo is right. The correct way to get exact results would be a shape database, not point proximity.

from aptimezones.

Please provide an exact example with code when the algorithm does not work correctly?

On 3 äåê. 2013, at 01:08, FutureTap [email protected] wrote:

Bringo is right. The correct way to get exact results would be a shape database, not point proximity.

—
Reply to this email directly or view it on GitHub.

from aptimezones.

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.

from aptimezones.

Thanks for your feedbacks, guys. We are working now on updating DB with USA states to make results more accurate for your country.

from aptimezones.

Same issue, lack of precision. Users from 2 places had issues with local time :

• Fort Worth
• Mississipi (don't know where exactly)

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.

from aptimezones.

Also I'm using country codes just in case you are wondering. Shapes is the way to go.

from aptimezones.

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.

from aptimezones.

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.

from aptimezones.

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.

from aptimezones.

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.

from aptimezones.

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.)

from aptimezones.

@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.

from aptimezones.

@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)

from aptimezones.