Description of problem: Anaconda 19.25 seems to be defaulting timezone now to Asia/Dhaka at least when I install from Japan. Version-Release number of selected component (if applicable): 19.25 Steps to Reproduce: 1. install Fedora 19 in Japan Actual results: Anaconda thinks timezone is Asia/Dhaka Expected results: Timezone to default to Asia/Tokyo Additional info: Is Dhaka being shown because of connecting to some Fedora mirror in that timezone? Geoip sounds cool at least earlier tz would default to Tokyo always for Japanese install.
(For reference Dhaka is the capital of Bangladesh - about 4.9Mm from Tokyo and 3 hours behind :)
Not seeing it any more.
(In reply to Jens Petersen from comment #0) > Is Dhaka being shown because of connecting to some Fedora mirror in that > timezone? > > Geoip sounds cool at least earlier tz would default to Tokyo always for > Japanese install. That could be it - Anaconda is currently using the MirrorManager API for getting the current territory code. But that API has a different primary goal - to get you the fastest mirror for your network. As a result, the territory code detection (for default language and timezone preset) might be swayed by a faster mirror in a nearby country. We already contacted the Fedora Infrastructure people & submitted a feature request ticket[1] for setting up a dedicated Fedora GeoIP service, that would not have these issue. Once that new API is up, issues like this should vanish. There is also an additional possibility - large corporate networks might be routing their Internet traffic through some distant central gateway. But the probability of a Japanese company having an Internet gateway in Bangladesh is rather low. :) [1] https://fedorahosted.org/fedora-infrastructure/ticket/3807
Location: America / Argentina / Buenos Aires Language: Spanish Detected by Anaconda: CLARO/TELMEX ......Portuguese(BRASIL) + America/Noronha Timezone SPEEDY/DSL ........Portuguese(BRASIL) + America/Noronha Timezone So, it is not ISP related. So, me too.
There's also the problem that this method can only ever get you a country code. I'm in Vancouver, Canada, which uses Pacific time. The geolocation stuff realizes I'm in Canada...and picks Newfoundland time, which is wrong by a full four and a half hours. We're a big country. =) I imagine this affects other 'wide' countries like the US, Russia and China too.
*** Bug 960763 has been marked as a duplicate of this bug. ***
(In reply to Adam Williamson from comment #5) > There's also the problem that this method can only ever get you a country > code. I'm in Vancouver, Canada, which uses Pacific time. The geolocation > stuff realizes I'm in Canada...and picks Newfoundland time, which is wrong > by a full four and a half hours. We're a big country. =) I imagine this > affects other 'wide' countries like the US, Russia and China too. If we can get an API that also returns an approximate city name, it might be possible to match it to a corresponding timezone. Eq. if you got "US" and "New York", it could be matched to "America/New_York". For most cities the city->timezone mapping would probably not be this straightforward though.
No, indeed, you'd need some smarts. I suppose I should note at this point that Ubiquity nails me right in Vancouver :)
Created attachment 756489 [details] Anaconda updates image that uses the new prelimanry Fedora GeoIP API So the Fedora Infrastructure people set up a very nice GeoIP API - so far the output seems to be very accurate! I've made an updates image, that makes Anaconda use this new API by default. Everyone is welcome to test it and report back their findings. :) If everything goes well, the API could be transferred from staging to production next week, to be ready for use before the Fedora final release.
just a note, martin - it's better for an updates.img to put it up on some public space (yours or anaconda team's fedorapeople.org space would be ideal) and link to that. Attaching it to a bug isn't great because you can't do 'updates=(somebugzillaattachment)' so people have to download it and either upload it to some space they have access to, or provide it via usb stick or whatever, which is more of a pain...
http://www.happyassassin.net/extras/new_geoip_API.img is the updates image Martin provided, for testing. thanks martin!
Well, with that updates.img I see America/Vancouver as the timezone on the hub, but also the installer crashes shortly after the hub appears, with "AttributeError: 'Environment' object has no attribute 'defaultoptions'" in file /tmp/updates/pyanaconda/ui/gui/utils.py . What tag did you build the updates.img from and what other changes did it include?
Created attachment 756775 [details] new updates image built against 19.30-1 compose Well, that still means it's working. :) That crash might have been caused by an outdated compose I used I built the updates image against. So I've made a new updates image built against a compose with Anaconda 19.30-1. The updates image was created from Anaconda git master + patch that makes Anaconda use the new API.
anaconda-19.30.4-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/anaconda-19.30.4-1.fc19
Package anaconda-19.30.5-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 anaconda-19.30.5-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-10652/anaconda-19.30.5-1.fc19 then log in and leave karma (feedback).
F19 was released and F20 will hopefully released soon. The bug is still set to ON_QA and Comment #13 indicates the issue as fixed. I think this bug-report should either be Closed or its Version set to 20 if there are still pending issues.