Author: klember
[Added to the original trac issue at 3.29pm, Saturday, 22nd March 2014]

I too would like this. We could use it in GNOME to do reverse geocoding of the computer's location to a timezone, so that we could automatically update the timezone when the user has travelled to another country.

Author: lonvia
[Added to the original trac issue at 8.05am, Monday, 7th April 2014]

This isn't really the core business of OSM. There are external sources available you can use to enhance the results with timezone data.

Author: klember
[Added to the original trac issue at 10.55am, Monday, 7th April 2014]

Which external sources do you have in mind? And do they have similar open data objectives as OSM?

Author: lonvia
[Added to the original trac issue at 12.03pm, Monday, 7th April 2014]

I was thinking of the tz database that you could mingle with geocoding results.

Let me clearify my earlier statement: first of all, I'm not aware that a consensus has been reached regarding time zone mapping. Some boundaries seem to have a timezone tag now which might be usable but requires resolving the timezone info of the complete hierarchy, not impossible but not trivial either. Second, I wouldn't consider time zone estimation a primary task of a geocoding server and using it primarily for time zone resolution sounds like overkill. Third, it should be easy enough to create a small timezone dataset that can be efficiently queried locally. So even if it might be an interesting feature, it will be so close to the end of a very long list of features to implement that 'wontfix' is closer to the truth than anything else. But by all means, prove me wrong and send a patch.

Author: lonvia
[Added to the original trac issue at 8.55pm, Thursday, 13th October 2016]

There is more or less a consensus in the OSM community that timezones don't belong into OSM. So, same goes for Nominatim. It simply won't happen.