Bug 1000022

Summary: time zone: New York is not the centre of the Universe
Product: [Fedora] Fedora Reporter: Karel Volný <kvolny>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: anaconda-maint-list, dshea, g.kaviyarasu, jonathan, kvolny, mkolman, sbueno, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-12 12:12:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Karel Volný 2013-08-22 14:01:35 UTC
Description of problem:
When trying to install F19, the installer pre-sets America/New York timezone. This is a bit annoying for the rest of the world ...

Version-Release number of selected component (if applicable):
19.30.13-1

How reproducible:
always

Steps to Reproduce:
1. have your machine connected in Brno, Czech Republic, for example
2. start the installation
3. when prompted, choose Czech language
4. look at the Datum & Čas (date and time) setting

Actual results:
America/New York

Expected results:
Europe/Prague

Additional info:
I don't know how big Czech community is there in New York, but I'd expect that for majority of the users who speak Czech, Europe/Prague would be more proper. If such a heuristic does not work (there are multiple languages that span more time zones) then at least use something neutral like UTC+0. While Red Hat started as an US company, it was 20 years ago and such US-centrism is quite a faux pas within the OSS community of the 21st century ...

Comment 1 Chris Lumens 2013-08-22 14:22:45 UTC
Instead of the lecture, you could instead consider that this is just a bug, not take it personally, and attach some log files to help us debug it?  Like /tmp/anaconda.log, perhaps.  Thanks.

Comment 2 Steve Tyler 2013-08-22 20:53:32 UTC
Are you installing from the DVD or Live image? Geolocation behaves slightly differently in the two cases:
Bug 975193 - geolocation works haphazardly

BTW, if I had my way, the only default time zone would be UTC ... :-)

Comment 3 Steve Tyler 2013-08-22 21:46:15 UTC
Also, note that geolocation depends on how your network is configured.

Here is what Kamil said in Bug 975193:

"Steps to Reproduce:
1. Connect from a network that is detected as in Czech Republic (that is not Red Hat's Brno office, by the way)."

A google.com search for "what is my ip address" will tell you what your IP address is.

With your IP address, you can run the "geoiplookup" command to find the country:
$ geoiplookup xx.xx.xx.xx

$ rpm -qf `which geoiplookup`
GeoIP-1.4.8-6.fc19.x86_64

If you want more precision, there are web sites that do geolocation for you:
http://www.maxmind.com/

Maxmind provides the geolocation database used by the geoiplookup command:
$ rpm -qi GeoIP | grep URL
URL         : http://www.maxmind.com/app/c

Comment 4 Steve Tyler 2013-08-23 15:54:40 UTC
Karel: Here is a way to find out what geolocation the installer will use:

$ curl https://geoip.fedoraproject.org/city

That URL is from the installer code to do geolocation:
https://git.fedorahosted.org/cgit/anaconda.git/tree/pyanaconda/geoloc.py

BTW, your network admins might be able to redirect such querys to a local server that would return locations in the Czech Republic ...

Comment 5 Martin Kolman 2013-09-12 12:12:25 UTC
That sounds like issues with your Internet connectivity, most probably caused by using a VPN or being on a corporate network that routes Internet connectivity through some remote gateway, which is in this case most probably somewhere in America.

So basically, the GeoIP lookup reports you are in America and sets the timezone accordingly (you can check anaconda.log for that).

BTW, selecting the Czech language will set the Prague timezone, but only if there are no results from GeoIP.

So in short, it is not possible to know if data provided by GeoIP is correct, so this is not a bug.