Skip to content
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

Open
timtrautmann opened this issue Nov 20, 2013 · 15 comments
Open

Timezone database should describe shapes not points #2

timtrautmann opened this issue Nov 20, 2013 · 15 comments
Assignees

Comments

@timtrautmann
Copy link

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
Copy link
Contributor

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.

@futuretap
Copy link

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

@SlavaBushtruk
Copy link
Contributor

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.

@kikolobo
Copy link

kikolobo commented Jan 7, 2014

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
Copy link
Contributor

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

@alexiscreuzot
Copy link

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
Copy link

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

@chriscdn
Copy link

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
Copy link

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
Copy link

tooluser commented Sep 2, 2014

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
Copy link

tooluser commented Sep 2, 2014

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.

@Krivoblotsky Krivoblotsky self-assigned this Apr 17, 2015
@mattjohnsonpint
Copy link

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
Copy link

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

@futuretap
Copy link

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

@akirmse
Copy link

akirmse commented Dec 3, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests