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 770579 - "Pyongyang" city in wrong country with wrong time zone
"Pyongyang" city in wrong country with wrong time zone
Status: RESOLVED FIXED
Product: libgweather
Classification: Core
Component: locations
3.20.x
Other Linux
: Normal normal
: future
Assigned To: libgweather-maint
libgweather-maint
Depends on:
Blocks:
 
 
Reported: 2016-08-29 22:00 UTC by lof
Modified: 2017-06-27 16:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Image of the bug with german locale (Südkorea = South Korea) (69.23 KB, image/png)
2016-08-29 22:00 UTC, lof
Details

Description lof 2016-08-29 22:00:54 UTC
Created attachment 334405 [details]
Image of the bug with german locale (Südkorea = South Korea)

I just searched for Pyongyang in gnome clocks 3.20. And clocks said the city was in South Korea (!) and applied the KST TZ of South Korea.

North Korea has UTC+8:30 while South Korea has UTC+9 (KST).
Comment 1 André Klapper 2016-08-30 11:37:21 UTC
Hmm, those strings come from the libgweather module but I cannot spot the string "Pjöngjang" in https://l10n.gnome.org/POT/libgweather.master/locations.master.de.po at all.
Confusing.

There is an entry but it is commented and hence not used:
#~ msgid "Pyongyang"
#~ msgstr "Pyǒngyang"
Comment 2 André Klapper 2016-08-30 11:44:18 UTC
<aday> clocks uses libgweather [...]. the country is possibly wrong because it works using the nearest airport to your location
Comment 3 Paolo Borelli 2016-08-30 12:53:09 UTC
Well, actually it tries to find the nearest airport in the same country. Of course there may be bugs, but I suggest to check if the data in libgweather is correct
Comment 4 Giovanni Campagna 2016-12-22 15:04:45 UTC
I added Pyongyang to the static database, which should fix this issue.
Previously, there was no city in North Korea the db, so it would go through
geocode and assign the closest known city (in South Korea).

Unfortunately, Paolo's comment that we respect country borders is incorrect,
because geocode-glib does not give us country information (even though it would
be available from the Nominatim API). But that's a different bug.
Comment 5 lof 2017-06-27 16:40:44 UTC
Just tested the newest Fedora Beta with 3.24 and the issue is fixed. Thank you Giovanni!