After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 727698 - automatic timezone anywhere in Israel reports "Hebron, Palestine, State of"
automatic timezone anywhere in Israel reports "Hebron, Palestine, State of"
Status: RESOLVED OBSOLETE
Product: gnome-control-center
Classification: Core
Component: Date and Time
3.10.x
Other Linux
: Normal normal
: ---
Assigned To: Kalev Lember
Control-Center Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-04-06 08:08 UTC by benjamin3harris
Modified: 2021-06-09 16:09 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description benjamin3harris 2014-04-06 08:08:47 UTC
At any location I've been able to find in Israel, tested in a number of different locations up and down the country, setting "Automatic Time Zone" to "ON" will set the time to "Hebron, Palestine, State of", which it says is "EEST", at UTC+03.

There are a couple of problems with this.

1. Time zone of the region is actually IDT/IST
2. There is no State of Palestine
Comment 1 Kalev Lember 2014-04-06 10:13:30 UTC
Yes, the automatic timezone is currently a bit fragile. It uses IP address geolocation and that is just not accurate enough in some cases. If you go to https://geoip.fedoraproject.org/city , do you get a location in Palestine as well?

In GNOME 3.12 we also have preliminary support for wifi based geolocation, based on the data from Mozilla Location Service. This should hopefully result in more accurate results in the future, once they get enough wifi data collected.

Regarding "State of Palestine", it seems to be in the ISO 3166 standard though: http://en.wikipedia.org/wiki/ISO_3166-2:PS . Is it wrong?

From /usr/share/xml/iso-codes/iso_3166.xml:

        <iso_3166_entry
                alpha_2_code="PS"
                alpha_3_code="PSE"
                numeric_code="275"
                name="Palestine, State of"
                official_name="the State of Palestine" />
Comment 2 benjamin3harris 2014-04-06 10:19:02 UTC
The fedoraproject link gets it right. It's interesting, actually, because I've seen my IP location on a number of sites and none of them have placed me in the West Bank or Gaza, so I'm not quite sure how Gnome is doing that.

Just for reference, here's the result of the fedoraproject link:

{"country_code3": "ISR", "longitude": 35.229999542236328, "dma_code": 0, "postal_code": null, "ip": "213.57.140.57", "country_code": "IL", "city": "Jerusalem", "country_name": "Israel", "region_name": "Yerushalayim", "area_code": 0, "metro_code": 0, "time_zone": "Asia/Jerusalem", "latitude": 31.780000686645508, "region": "06"}

As for the "State of Palestine," it appears I need to take that up with ISO, since that does appear to be their standard. Thanks.
Comment 3 Zeeshan Ali 2014-04-06 10:46:08 UTC
(In reply to comment #0)
> At any location I've been able to find in Israel, tested in a number of
> different locations up and down the country, setting "Automatic Time Zone" to
> "ON" will set the time to "Hebron, Palestine, State of", which it says is
> "EEST", at UTC+03.
> 
> There are a couple of problems with this.
> 
> 1. Time zone of the region is actually IDT/IST

As Kalev explained, we rely on IP database, provided by maxmind.com. If you have Wifi device present and enabled on your machine, geoclue (the component resposnsible for finding your location) can use that too but your neighbourhood wifi networks need to be in Mozilla's database. The good news is that they provide you with an easy way to contribute that:

https://wiki.mozilla.org/CloudServices/Location#Contributing

Having said that, it wont currently help you here as settings-daemon is only asking for city-level accuracy and wifi-based geolocation source provide neighbourhood-level accuracy (geoclue doesn't provide more accurate than requested accuracy for privacy reasons).

Perhaps it won't be too bad if settings-daemon asked for neighbourhood-level accuracy instead?

> 2. There is no State of Palestine

Please don't push your political views here: http://en.wikipedia.org/wiki/State_of_Palestine . The relavent issues here is only that we don't track your location correctly.
Comment 4 Kalev Lember 2014-04-06 13:52:23 UTC
(In reply to comment #2)
> The fedoraproject link gets it right. It's interesting, actually, because I've
> seen my IP location on a number of sites and none of them have placed me in the
> West Bank or Gaza, so I'm not quite sure how Gnome is doing that.
> 
> Just for reference, here's the result of the fedoraproject link:

OK, so the way we try to figure out the timezone is a multi process step.

First step is to get coordinates from some source, which in your case is IP geolocation returning latitude=31.780000686645508 and longitude=35.229999542236328. We don't use any other data from the geoip result besides the coordinates.

Next step is to query openstreetmap.org to find out what's at those coordinates. The query to test this is: http://nominatim.openstreetmap.org/reverse?format=xml&lat=31.780000686645508&lon=35.229999542236328 -- and this returns Palestina.

And finally, we go and find the closest city within the country and map this to a timezone.
Comment 5 Zeeshan Ali 2014-04-06 21:55:25 UTC
(In reply to comment #3)
> (In reply to comment #0)
> > At any location I've been able to find in Israel, tested in a number of
> > different locations up and down the country, setting "Automatic Time Zone" to
> > "ON" will set the time to "Hebron, Palestine, State of", which it says is
> > "EEST", at UTC+03.
> > 
> > There are a couple of problems with this.
> > 
> > 1. Time zone of the region is actually IDT/IST
> 
> As Kalev explained, we rely on IP database, provided by maxmind.com. If you
> have Wifi device present and enabled on your machine, geoclue (the component
> resposnsible for finding your location) can use that too but your neighbourhood
> wifi networks need to be in Mozilla's database. The good news is that they
> provide you with an easy way to contribute that:
> 
> https://wiki.mozilla.org/CloudServices/Location#Contributing
> 
> Having said that, it wont currently help you here as settings-daemon is only
> asking for city-level accuracy and wifi-based geolocation source provide
> neighbourhood-level accuracy (geoclue doesn't provide more accurate than
> requested accuracy for privacy reasons).
> 
> Perhaps it won't be too bad if settings-daemon asked for neighbourhood-level
> accuracy instead?

Actually this won't work either as wifi provides street-level accuracy. I wonder if that would be acceptable to users.
Comment 6 Bastien Nocera 2014-04-07 10:37:26 UTC
(In reply to comment #5)
> Actually this won't work either as wifi provides street-level accuracy. I
> wonder if that would be acceptable to users.

Can't we ask geoclue to give us the most precise location using the available hardware? Eg. presumably WiFi is already enabled and available, and we could try that. If privacy is a concern, given the privacy leak to the user's session, maybe the timezone switching should be implemented system-wide instead...

(In reply to comment #4)
> (In reply to comment #2)
> > The fedoraproject link gets it right. It's interesting, actually, because I've
> > seen my IP location on a number of sites and none of them have placed me in the
> > West Bank or Gaza, so I'm not quite sure how Gnome is doing that.
> > 
> > Just for reference, here's the result of the fedoraproject link:
> 
> OK, so the way we try to figure out the timezone is a multi process step.
> 
> First step is to get coordinates from some source, which in your case is IP
> geolocation returning latitude=31.780000686645508 and
> longitude=35.229999542236328. We don't use any other data from the geoip result
> besides the coordinates.
> 
> Next step is to query openstreetmap.org to find out what's at those
> coordinates. The query to test this is:
> http://nominatim.openstreetmap.org/reverse?format=xml&lat=31.780000686645508&lon=35.229999542236328
> -- and this returns Palestina.

This is where I would expect OSM to give us the timezone directly, instead of having to go through this loss of precision.

> And finally, we go and find the closest city within the country and map this to
> a timezone.

That'll probably break in quite a few cases where that city is on a border. That includes our GUADEC 2014 venue, Strasbourg:
http://en.wikipedia.org/wiki/Border_town#List_of_border_towns_and_cities
Comment 7 Kalev Lember 2014-04-07 10:45:45 UTC
(In reply to comment #6)
> This is where I would expect OSM to give us the timezone directly, instead of
> having to go through this loss of precision.

OSM ticket to add timezone to the results got just closed as WONTFIX.

https://trac.openstreetmap.org/ticket/4200
Comment 8 Bastien Nocera 2014-04-07 10:49:04 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > This is where I would expect OSM to give us the timezone directly, instead of
> > having to go through this loss of precision.
> 
> OSM ticket to add timezone to the results got just closed as WONTFIX.
> 
> https://trac.openstreetmap.org/ticket/4200

I'd reopen it and ask which external sources. Or even external sources with similar APIs and open data objectives as OSM. Yahoo PlaceFinder could give us that...
Comment 9 Zeeshan Ali 2014-04-07 13:00:01 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Actually this won't work either as wifi provides street-level accuracy. I
> > wonder if that would be acceptable to users.
> 
> Can't we ask geoclue to give us the most precise location using the available
> hardware? Eg. presumably WiFi is already enabled and available, and we could
> try that.

That would a big shift in how I've designed the sources to work in geoclue and will complicate the code quite a bit, ignoring the privacy issue. Besides that doesn't sound any better than settings-daemon explicitly asking for most precise location.

Since I'm about to port geoclue to also use mozilla location service for IP, I'm hoping that they'll in near future allow submitting/correcting IP info as well. Then we can simply direct users to mozstumbler and hope that most people have an android (or GPS modem on their laptop so we can ask them to enable submission of data from geoclue).

> If privacy is a concern, given the privacy leak to the user's
> session, maybe the timezone switching should be implemented system-wide
> instead...

Maybe. What exactly you have in mind how that would work?
Comment 10 Bastien Nocera 2014-04-07 13:15:12 UTC
(In reply to comment #9)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > Actually this won't work either as wifi provides street-level accuracy. I
> > > wonder if that would be acceptable to users.
> > 
> > Can't we ask geoclue to give us the most precise location using the available
> > hardware? Eg. presumably WiFi is already enabled and available, and we could
> > try that.
> 
> That would a big shift in how I've designed the sources to work in geoclue and
> will complicate the code quite a bit, ignoring the privacy issue. Besides that
> doesn't sound any better than settings-daemon explicitly asking for most
> precise location.

True. It would be a problem in terms of power usage when a GPS is available. But in those cases, other (and probably better) means of determining the location would be available (such as all the metadata given out by GSM base stations). Probably not worth implementing then.

> Since I'm about to port geoclue to also use mozilla location service for IP,
> I'm hoping that they'll in near future allow submitting/correcting IP info as
> well. Then we can simply direct users to mozstumbler and hope that most people
> have an android (or GPS modem on their laptop so we can ask them to enable
> submission of data from geoclue).
> 
> > If privacy is a concern, given the privacy leak to the user's
> > session, maybe the timezone switching should be implemented system-wide
> > instead...
> 
> Maybe. What exactly you have in mind how that would work?

Pretty much the same way? :)

Not sure it's worth expanding too much on this right now, but I could see this as a way to avoid triggering the timezone changes too much on multi-user systems, and avoid leaking the information to the user session. But multi-user mobile systems aren't that widespread, so probably not worth optimising for, and we'll hopefully soon get sandboxing, which would stop other session programs from getting that information. I was merely thinking out loud :)

To solve the problems mentioned in this bug, I would however:
- make sure that the highest possible degree of location precision is used (and make sure that gnome-settings-daemon uses some geofencing to avoid retriggering calculations when the location changes very little)
- and find a better way to find the timezone based on the location. The current way is likely to cause a number of problems for the cities I mentioned, and probably in a lot of other cases too (any town on the border of a timezone for example).
Comment 11 Kalev Lember 2014-04-07 13:48:06 UTC
My preference would be to use some web service for doing the coordinates -> timezone mapping so we don't have to maintain a map database ourselves. And yeah, the way we do it right now is not great and fails in a lot of corner cases. It might be good enough for an installer / initial setup utility where the user is in a good position to manually review the detected location, but not for automatic updates.

Are there any other services we could use besides OSM if they are unwilling to add timezone to the results?

One offline database I was able to find that seems at least minimally maintained is http://efele.net/maps/tz/world/ . But still, it's lagging behind tzdata and doesn't yet have the recent Crimea changes, for example.
Comment 12 Kalev Lember 2014-04-07 13:55:36 UTC
(In reply to comment #9)
> (In reply to comment #6)
> > Can't we ask geoclue to give us the most precise location using the available
> > hardware? Eg. presumably WiFi is already enabled and available, and we could
> > try that.
> 
> That would a big shift in how I've designed the sources to work in geoclue and
> will complicate the code quite a bit, ignoring the privacy issue. Besides that
> doesn't sound any better than settings-daemon explicitly asking for most
> precise location.

I am not sure it makes sense to let users choose the privacy level in a UI. Is it something that other OS's are doing? Can't we get away with just showing a simple on/off switch with 'Share my location' / 'Do not share my location' for each app?

If we didn't have the privacy levels, it should be straightforward to use the most precise source that's available, as opposed to always using IP geolocation as we do now.
Comment 13 Bastien Nocera 2014-04-07 14:03:43 UTC
(In reply to comment #12)
> (In reply to comment #9)
> > (In reply to comment #6)
> > > Can't we ask geoclue to give us the most precise location using the available
> > > hardware? Eg. presumably WiFi is already enabled and available, and we could
> > > try that.
> > 
> > That would a big shift in how I've designed the sources to work in geoclue and
> > will complicate the code quite a bit, ignoring the privacy issue. Besides that
> > doesn't sound any better than settings-daemon explicitly asking for most
> > precise location.
> 
> I am not sure it makes sense to let users choose the privacy level in a UI.

Don't know where you got that idea from. Neither Zeeshan nor myself said that.

> Is
> it something that other OS's are doing? Can't we get away with just showing a
> simple on/off switch with 'Share my location' / 'Do not share my location' for
> each app?
> 
> If we didn't have the privacy levels, it should be straightforward to use the
> most precise source that's available, as opposed to always using IP geolocation
> as we do now.

I think that there should be a way for gnome-settings-daemon to ask for the most precise available location *without enabling new hardware*. If the GPS isn't on, but the 3G card is, you can use the MNC/MCC metadata. If there's no 3G hardware, use the Wi-Fi APs triangulation, etc.
Comment 14 Bastien Nocera 2014-04-07 14:06:31 UTC
(In reply to comment #11)
> My preference would be to use some web service for doing the coordinates ->
> timezone mapping so we don't have to maintain a map database ourselves. And
> yeah, the way we do it right now is not great and fails in a lot of corner
> cases. It might be good enough for an installer / initial setup utility where
> the user is in a good position to manually review the detected location, but
> not for automatic updates.
> 
> Are there any other services we could use besides OSM if they are unwilling to
> add timezone to the results?

That's the reason why I asked for the bug to be reopened so that the person who closed the OSM bug can tell us which databases they had in mind.

> One offline database I was able to find that seems at least minimally
> maintained is http://efele.net/maps/tz/world/ . But still, it's lagging behind
> tzdata and doesn't yet have the recent Crimea changes, for example.

Maintaining our own database is likely to be very time consuming. What does FirefoxOS use for that? I'm guessing they might use metadata from the GSM network instead for phones, but for tablets without 3G, they'd have the same requirements as us for laptops.
Comment 15 Kalev Lember 2014-04-07 14:18:44 UTC
(In reply to comment #14)
> That's the reason why I asked for the bug to be reopened so that the person who
> closed the OSM bug can tell us which databases they had in mind.

Yes, I've already reopened the ticket and asked this.
Comment 16 Zeeshan Ali 2014-04-07 14:31:22 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #6)
> > > (In reply to comment #5)
> 
> To solve the problems mentioned in this bug, I would however:
> - make sure that the highest possible degree of location precision is used

I am not sure its a good idea to asks for highest possible precision. Network is needed anyway for geocoding and we are very likely to get correct location with street-level accuracy already and when we fail, we have a way to get user to fix it for us (using mozsubmler). :)

> (and
> make sure that gnome-settings-daemon uses some geofencing to avoid retriggering
> calculations when the location changes very little)

The conclusion of my discussion with Kalev IIRC on this was that setting-daemon should listen to network going up and down and ask geoclue for location each time it goes up so that geoclue process doesn't need to keep running all the time and shell doesn't end up with 'location in use' icon permanently if autotz is enabled.

> - and find a better way to find the timezone based on the location. The current
> way is likely to cause a number of problems for the cities I mentioned, and
> probably in a lot of other cases too (any town on the border of a timezone for
> example).

I was discussing this with Mattias yesterday and we agreed that the best way to solve this would be to have our own local DB for this as it won't be a lot of data and changes are not expected to be frequent. This would also mean we don't depend on network or any service.
Comment 17 Zeeshan Ali 2014-04-07 14:39:29 UTC
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #9)
> > > (In reply to comment #6)
> > > > Can't we ask geoclue to give us the most precise location using the available
> > > > hardware? Eg. presumably WiFi is already enabled and available, and we could
> > > > try that.
> > > 
> > > That would a big shift in how I've designed the sources to work in geoclue and
> > > will complicate the code quite a bit, ignoring the privacy issue. Besides that
> > > doesn't sound any better than settings-daemon explicitly asking for most
> > > precise location.
> > 
> > I am not sure it makes sense to let users choose the privacy level in a UI.
> 
> Don't know where you got that idea from. Neither Zeeshan nor myself said that.

Yeah. While geoclue allows agent to dictate how much accuracy an app is allowed to have, I don't imagine that being actually used but rather agent could tell user what level of accuracy is requested and user can take that into consideration for deciding whether or not they are comfortable sharing that.

Since we'd want gnome-settings-daemon to be white-listed, and user will not see this information, I'd rather it only uses an accuracy that most users are likely to be comfortable with. Thats what I meant by 'privacy concerns' here.
Comment 18 Kalev Lember 2014-04-07 14:47:32 UTC
(In reply to comment #16)
> I was discussing this with Mattias yesterday and we agreed that the best way to
> solve this would be to have our own local DB for this as it won't be a lot of
> data and changes are not expected to be frequent. This would also mean we don't
> depend on network or any service.

Sure, if you are willing to maintain an offline database somewhere and keeping it up to date with tzdata package updates, I am very much looking forward to using it. In fact, I would *love* having a better data source than what we have now. I'm not volunteering to maintain the database myself, though.
Comment 19 Zeeshan Ali 2014-04-07 15:05:07 UTC
(In reply to comment #18)
> (In reply to comment #16)
> > I was discussing this with Mattias yesterday and we agreed that the best way to
> > solve this would be to have our own local DB for this as it won't be a lot of
> > data and changes are not expected to be frequent. This would also mean we don't
> > depend on network or any service.
> 
> Sure, if you are willing to maintain an offline database somewhere and keeping
> it up to date with tzdata package updates, I am very much looking forward to
> using it. 

Not me, Mattias wants to do that. :)
Comment 20 Mattias Bengtsson 2014-04-07 17:21:37 UTC
(In reply to comment #19)
> (In reply to comment #18)
> > (In reply to comment #16)
> > > I was discussing this with Mattias yesterday and we agreed that the best way to
> > > solve this would be to have our own local DB for this as it won't be a lot of
> > > data and changes are not expected to be frequent. This would also mean we don't
> > > depend on network or any service.
> > 
> > Sure, if you are willing to maintain an offline database somewhere and keeping
> > it up to date with tzdata package updates, I am very much looking forward to
> > using it. 
> 
> Not me, Mattias wants to do that. :)

Yeah I have some other stuff in the pipe currently and I'm also really busy with work and stuff. However I'd love to work on this and I have some ideas on how to do it already. 

Hopefully I'll be able to join the Location hackfest and I can start working on it there.
Comment 21 Mattias Bengtsson 2014-04-07 17:52:52 UTC
A quick google and I found this: http://efele.net/maps/tz/world/

The header is "A shapefile of the TZ timezones of the world" and it also seem to be updated and maintained. 

The way I would do this is either:
 1) import the shapefile[1] into a spatialite[2] database and then it should be fairly simple to query that for the tz of a coordinate
 2) do the spatial search using some handwritten code if the spatialite dependency is too much


1: http://en.wikipedia.org/wiki/Shapefile
2: https://www.gaia-gis.it/fossil/libspatialite/index
Comment 22 Zeeshan Ali 2014-04-07 18:06:27 UTC
* Turns out that Mozilla uses commercial version of maxmind.com geoip database so its supposed to be more accurate, don't know how much exactly but at least somewhat. So when I switch to Mozilla for geoip (hopefully in this week), we should get more accurate results from geoip source.

* Collection of IPs is in the plans for near future (June): https://wiki.mozilla.org/CloudServices/Location/Roadmap . Once that is in place, the accuracy will not only increase over time, there will be an easy way for users to correct the records themselves.
Comment 23 Mattias Bengtsson 2014-04-07 18:16:28 UTC
(In reply to comment #21)
> A quick google and I found this: http://efele.net/maps/tz/world/
> 
> The header is "A shapefile of the TZ timezones of the world" and it also seem
> to be updated and maintained. 

Okay I just saw Kalev's reply above, the latest update of that tz shapefile is from Nov '13 which isn't long ago (but maybe too long?).
Comment 24 Zeeshan Ali 2014-04-15 23:14:55 UTC
Benjamin, Could you please check (using the data provided in comment#4) if its your coordinates that are wrong or reverse-geocoding results from Nominatim? If its former, I just rolled a new release of geoclue where geoip should be more reliable so it might fix your issue. If its latter, you can actually correct this yourself using openstreemap editors: http://wiki.openstreetmap.org/wiki/Comparison_of_editors .
Comment 25 Mattias Bengtsson 2014-05-27 00:21:55 UTC
Did a little testing tonight at the airport (and a little now tonight) with the timezone Shapefile. Seems to work fine. 
Using the coordinates for Kehl and Strasbourg (that was mentioned earlier) I get the correct result for example.

A makefile to compile the shapefile to a spatialite database and some simple tests are here:
https://gist.githubusercontent.com/moonlite/69937a704c07e92b3db0/raw/720a9b0fc4a460e1cc9983745414f843f0b3499e/Makefile

It might ask you to install spatialite-tools

Just do:
$ make 
$ make test
Comment 26 Mattias Bengtsson 2014-05-27 00:24:51 UTC
The database is roughly 40MB (xz-compressed it's about 10MB), not sure if that's too much.
Comment 27 Kalev Lember 2014-05-27 10:23:07 UTC
That's awesome, thanks. No, I don't think a 40 MB data file is too much, that would be perfectly fine.

To make this work for system wide timezone geolocation, we'd need the database and its wrapper library in a separate git repo. gnome-settings-daemon would then depend on the new library and use that for timezone lookup, instead of the current code.

Also, I've asked for clarification for the WONTFIX in the OSM timezone ticket (https://trac.openstreetmap.org/ticket/4200) and they suggested going with a local database as well.
Comment 28 Mattias Bengtsson 2014-05-27 10:42:28 UTC
Cool! I'll start working on this when time permits. It will have to wait until at least I've merged the routing in Maps.
Comment 29 Mattias Bengtsson 2014-05-27 11:36:09 UTC
Btw, doing this inside a spatial database (like sqlite+spatialite) lets us do more advanced queries. 

One thing we could do quite easily for example is to say that we only do automatic timezone change if the whole accuracy circle is inside a timezone polygon.
Comment 30 Bastien Nocera 2014-05-28 10:04:59 UTC
(In reply to comment #29)
> Btw, doing this inside a spatial database (like sqlite+spatialite) lets us do
> more advanced queries. 
> 
> One thing we could do quite easily for example is to say that we only do
> automatic timezone change if the whole accuracy circle is inside a timezone
> polygon.

40 megs is a bit too big for us to use on a live system, as we'd need to either uncompress this amount of data in RAM (devices with 1GB of RAM won't like it), on disk (machines with slow disks will already have a less than pleasant experience booting up, and that's when we react), or just have it shipped in distributions, which will mean another level of software maintenance.

Can this data be offered as a web service instead? We can probably cache the results, or offer enough data in the answer that we don't need to constantly query it (eg. tell us the fence to cross before re-querying).
Comment 31 Mattias Bengtsson 2014-05-29 15:51:22 UTC
(In reply to comment #30)
> (In reply to comment #29)
> > Btw, doing this inside a spatial database (like sqlite+spatialite) lets us do
> > more advanced queries. 
> > 
> > One thing we could do quite easily for example is to say that we only do
> > automatic timezone change if the whole accuracy circle is inside a timezone
> > polygon.
> 
> 40 megs is a bit too big for us to use on a live system, as we'd need to either
> uncompress this amount of data in RAM (devices with 1GB of RAM won't like it),
> on disk (machines with slow disks will already have a less than pleasant
> experience booting up, and that's when we react), or just have it shipped in
> distributions, which will mean another level of software maintenance.

Yeah my thought was to make a wrapper library around this that would be shipped with the distributions. I'd be willing to maintain that library, but are worried about the maintenance in the distributions?

> Can this data be offered as a web service instead? We can probably cache the
> results, or offer enough data in the answer that we don't need to constantly
> query it (eg. tell us the fence to cross before re-querying).

Sure that would be possible. I had the impression that there were use cases for when you'd want to do a coordinate → timezone conversion while being offline, though thinking about it I guess it doesn't make much sense since wifi- and ip geolocation (which I'd guess makes up for the overwhelming majority) requires internet access anyways. 

So yeah, I guess an internet service would make sense.
Comment 32 John Layt 2014-05-29 18:51:06 UTC
Sounds great, I'd been planning on doing exactly this myself, just never had the time :-) If this is available as a DBus or online service or similar then KDE would be very interested in using it as well.

A couple of comments, apologies if you've already thought of these.

The 40MB file is fairly big, it's fine for desktop installs but other use cases would suffer.  I believe the guy who created it used the VMAP0 data set which has a very high level of detail that wouldn't really be needed in most cases (I wish he would use Natural Earth data instead, it's more up-to-date and compact).  Reducing the level of detail (number of points), or the precision of each point could easily halve or quarter the size of the data.  There's well-know routines in the likes of QGIS or GDAL that do this.  You could provide two datasets, one vastly simplified for installers or limited resource environments, and the full set for desktop use.  Alternatively, Natural Earth does have a start at a tz dataset that is currently only 2.5MB uncompressed (http://www.naturalearthdata.com/downloads/10m-cultural-vectors/timezones/), it's missing a *lot* of detail but they may be open to collaborating to create a more complete dataset.

A web api would be great, I can see a lot of other people beyond Gnome/KDE/Mozilla finding it useful.  It's a shame OSM seems so resistant to adding tz data to nominatim, but perhaps they would be more interested in hosting it as a separate service?  Some input from them would be good, it's their area of expertise :-)  Or maybe talk to the IANA who now host/manage the Olson tz database, they may see benefit in it.  Otherwise I could probably get the KDE sysadmins to host a copy of the server so KDE users are not stressing Gnome resources.
Comment 33 Mattias Bengtsson 2014-06-02 22:03:08 UTC
(In reply to comment #32)
> Sounds great, I'd been planning on doing exactly this myself, just never had
> the time :-) If this is available as a DBus or online service or similar then
> KDE would be very interested in using it as well.

Great. :)

> A couple of comments, apologies if you've already thought of these.
> 
> The 40MB file is fairly big, it's fine for desktop installs but other use cases
> would suffer.  I believe the guy who created it used the VMAP0 data set which
> has a very high level of detail that wouldn't really be needed in most cases (I
> wish he would use Natural Earth data instead, it's more up-to-date and
> compact).  Reducing the level of detail (number of points), or the precision of
> each point could easily halve or quarter the size of the data.  There's
> well-know routines in the likes of QGIS or GDAL that do this.  You could
> provide two datasets, one vastly simplified for installers or limited resource
> environments, and the full set for desktop use.  

Yeah I was thinking of doing something like this as well. 

> Alternatively, Natural Earth does have a start at a tz dataset that is currently
> only 2.5MB uncompressed
> (http://www.naturalearthdata.com/downloads/10m-cultural-vectors/timezones/),
> it's missing a *lot* of detail but they may be open to collaborating to create
> a more complete dataset.

Will take a look, however no updates in the last two years doesn't sound encouraging. :(

Btw, I'd like to state that if someone wants to take a stab at this they should by all means do so. I'm pretty busy at the moment and although I'm excited to work on this, realistically speaking I might not have time for this in a while (or at all).
Comment 34 André Klapper 2021-06-09 16:09:35 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new bug report at
  https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/

Thank you for your understanding and your help.