Timezone database should describe shapes not points

[timtrautmann]

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.

[Krivoblotsky]

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 notifications@github.com íàïèñàâ(ëà):

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.

[futuretap]

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

[SlavaBushtruk]

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

On 3 äåê. 2013, at 01:08, FutureTap notifications@github.com 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.

[kikolobo]

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.

[Krivoblotsky]

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

[alexiscreuzot]

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.

[alexiscreuzot]

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

[chriscdn]

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.

[predator747]

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.

[tooluser]

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.

[tooluser]

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.

[mattjohnsonpint]

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

[chriscdn]

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