Bug 442112 - provide more city options for timezone configuration
Summary: provide more city options for timezone configuration
Status: CONFIRMED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Digital Clock widget (show other bugs)
Version: 5.22.5
Platform: Arch Linux Linux
: NOR wishlist
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-09-07 08:27 UTC by Vasil Yonkov
Modified: 2021-09-17 13:16 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vasil Yonkov 2021-09-07 08:27:07 UTC
When I try to add cities to the list of time zones, the "Add More Timezones" search list is missing cities like Mumbai [1], Beijing [2] and Auckland [3].

Maybe the source for this information should be updated or changed.

[1] https://www.timeanddate.com/worldclock/india/mumbai
[2] https://www.timeanddate.com/worldclock/china/beijing
[3] https://www.timeanddate.com/worldclock/new-zealand/auckland

SOFTWARE/OS VERSIONS
OS: Arch Linux
KDE Plasma Version: 5.22.5
KDE Frameworks Version: 5.85.0
Qt Version: 5.15.2
Comment 1 Nate Graham 2021-09-08 21:15:14 UTC
I see Beijing, listed under "Shanghai Asia/China (Beijing Time)".

I also see Auckland. I don't see Mumbai though.

I wonder where this data comes from. Since it differs between us, that's a bit odd, and suggests a differing source between distros. Will investigate a bit.
Comment 2 Nate Graham 2021-09-09 16:09:31 UTC
OK, this data does exist under our control in timezonesi18n.cpp. And indeed Mumbai and Beijing are missing. Auckland is in there though.
Comment 3 Harald Sitter 2021-09-10 14:03:16 UTC
Beijing and Mumbai have no timezone, neither do they have an alias timezone. That is why they are not modeled at all. Adding aliases for them needs taking up with the IANA, not us.

There is a problem with our list though, it is maintained by hand and therefore wildly incomplete. We appear to missing at least 50 or so city aliases compared to what is in my tzdata.zi. Should be solvable with some scripting magic so we can extract data out of tzdata rather than having to add entries by hand.
Comment 4 Vasil Yonkov 2021-09-10 18:35:29 UTC
Thank you for working on this issue.

I must've misspelled Auckland when I was trying to come up with examples.

Sometimes I interact with people from places like that and it's convenient to
have the clock show their time. That's my use case.

I was using gnome for a while and the clock there had all cities I needed, so my
thinking was that you probably use an incomplete source. I was surprised when
you said you maintain an explicit list of cities. It will indeed be much better
if you can get the list automatically from a source that specializes in keeping
track of timezones and that sort of stuff.
Comment 5 Harald Sitter 2021-09-13 11:21:36 UTC
(In reply to Vasil Yonkov from comment #4)
> I was using gnome for a while and the clock there had all cities I needed,

Uh! Now that is a useful bit of information.

Looking at the code, gnome lets you define any city it knows about via its weather library libgweather and that simply has all the data hardcoded https://gitlab.gnome.org/GNOME/libgweather/-/tree/master/data this data then is used to power both the weather system and the clock system because the locations also have their timezones specified.

Being able to specifying most larger cities is of course heaps nicer than being limited to the ones actually exposed as timezones. Sooooo we could/should perhaps find a way to do the same.

One option would be to also use libgweather, there's no reason to duplicate existing data TBH. Main advantage is that this works offline. We could also use only the data without the library (ideally without copying the data - though that is tricky because of translations I suspect).

Another option would be to check if any of the weather services we have already knows timezones. Tricky bit then of course is the city/country name returned by the service isn't necessarily in the system's locale so the search may go off sideways (which I expect is one of the reasons libgweather maintains its own database of locations).  Disadvantage: only online.

Yet another option would be to see if geoip.kde.org can extract cities out of its backing data. Disadvantage: only online.

geonames.org has comprehensive data tables on this that we could strip down to the necessary data set and use. Disadvantage: no translations. There may be better data sources but I couldn't find any just now.

Obviously we could also opt to only offer advanced city selection only when online.

Needs someone to actually do some more research and put in the work.