Bug 1031319

Created attachment 824964 [details]
anaconda.log from final TC1

Created attachment 824965 [details]
journalctl from final TC1

Remaining booted in final TC1, merely quit anaconda and relaunch in the same session, anaconda.log no longer indicates an error yet it still gets says the timezone is Pacific/Honolulu.

14:22:30,648 INFO anaconda: Running Thread: AnaGeolocationRefreshThread (140469542561536)
14:22:30,650 INFO anaconda: Starting geolocation lookup
14:22:30,651 INFO anaconda: Geolocation provider: Fedora GeoIP
14:22:31,136 INFO anaconda: Geolocation lookup finished in 0.5 seconds
14:22:31,143 INFO anaconda: got results from geolocation
14:22:31,171 INFO anaconda: Thread Done: AnaGeolocationRefreshThread (140469542561536

I just received Pacific/Honolulu timezone in my installation as well. (I should be detected around Europe/Amsterdam).

Reassigning to langtable - it is returning a list of US timezones with Honolulu as the first item. As the timezones should be ordered demographically, this is a bug in the reordering.

langtable-0.0.21-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/langtable-0.0.21-1.fc20

langtable-0.0.21-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/langtable-0.0.21-1.fc19

The bug as described is not fixed with this update. Now the timezone is incorrectly reported as America/New York, so the geolocation feature still isn't working correctly.

(In reply to Chris Murphy from comment #8)
> The bug as described is not fixed with this update. Now the timezone is
> incorrectly reported as America/New York, so the geolocation feature still
> isn't working correctly.

Right, it only improves the result slightly when geolocation failed
for whatever reason. langtable only has information of what timezones
are most likely when you know the country (and maybe the language).

Package langtable-0.0.21-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing langtable-0.0.21-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-21833/langtable-0.0.21-1.fc19
then log in and leave karma (feedback).

Well, I would say it is fixed, as:
* if connectivity is available and the API works, language & timezone are correctly selected
* if connectivity is not available or the GeoIP API does not work for some reason, America/New York, the long standing Anaconda default timezone, is used.

BTW, this is the URL for the GeoIP API:
https://geoip.fedoraproject.org/city
It should return a JSON looking +- like this:

{"dma_code": 0, "ip": "<ip removed>", "longitude": -0.12999999523162842, "latitude": 51.5, "region_name": null, "region": null, "area_code": 0, "city": null, "postal_code": null, "time_zone": "Europe/London", "country_code": "GB", "country_code3": "GBR", "metro_code": 0, "country_name": "United Kingdom"}

So if the URL is reachable and returns a sane looking JSON, but Anaconda does not preselect a correct language and timezone, then there is an issue. Otherwise it is working correctly.

In the November Ananconda betas, the city of Montreal 
american/montreal disappeared from the list and from the map.

why?

And the first beta put my timezone to that of Denver. My default based on my IP address should be Toronto, Montreal or New York.

The second beta now puts my default TZ as Honolulu.

I am very open to trying the next beta.  BTW, I always do a DVD image install to a 250 gig physical disk, reserved for this.  The real disk install shows up things that a VM install does not.

(In reply to Martin Kolman from comment #11)
> Well, I would say it is fixed, as:
> * if connectivity is available and the API works, language & timezone are
> correctly selected

I have connectivity, language & timezone are not correctly selected.

https://geoip.fedoraproject.org/city

{"region": null, "country_code": "US", "metro_code": 0, "country_code3": "USA", "area_code": 0, "region_name": null, "latitude": 38.0, "time_zone": null, "postal_code": null, "longitude": -97.0, "city": null, "dma_code": 0, "country_name": "United States", "ip": "50.183.15.223"}

leslie: as I posted to the forums, please file a new bug for Montreal going missing.

And on a cell network:

{"region": null, "area_code": 0, "region_name": null, "longitude": -97.0, "latitude": 38.0, "dma_code": 0, "ip": "172.56.8.97", "metro_code": 0, "country_name": "United States", "country_code": "US", "country_code3": "USA", "time_zone": null, "postal_code": null, "city": null}

langtable-0.0.21-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Guys, you really need to file separate reports. This one (Honolulu as a fallback timezone) has been fixed.

(In reply to Adam Williamson from comment #15)
> leslie: as I posted to the forums, please file a new bug for Montreal going
> missing.

Adam, Since the two problems arrivec coincidentally, I attributed it to being one and the same. Fix the problem with wrong url and the missing America/Montreal would reappear.

I live here and would be disappointed if Montreal was wiped off the map.

Yes, I will open a new buglet report.

langtable-0.0.22-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/langtable-0.0.22-1.fc19

langtable-0.0.23-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/langtable-0.0.23-1.fc19

*** Bug 1033889 has been marked as a duplicate of this bug. ***

langtable-0.0.23-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.