Although, as an example, ISO 8601 permits both T00:00Z and T00:00+00:00, having “UTC” (in addition to UTC+00:00) appears redundant for a user.
Does the underlying library differentiate between UTC versus UTC with an offset equal to 0 in any meaningful manner?
Additionally, “Etc/UTC” being a another separate option is especially baffling.
These definitions come from IANA’s timezone database.
UTC, UTC+00:00 and Etc/UTC are essentially the same
There are benefits to using the official standard IANA maintained time zone names - even if some are duplicate.
There are many more duplicate time zones all over the place - for example there two US Central timezones defined, which are identical, and 18 Australian time zones - even though Australia has only 5 distinct time zones. There’s no point in trying to remove duplicates: it will be impossible for KDE maintainers to choose “the right one”, and it will inevitably cause problems when people go looking for the thing they know should be there but doesn’t exist.
This comment in IANA’s tzdata suggests that the existence of “UTC” is about supporting legacy code, rather than an all-out endorsement:
$ grep -B 2 'UTC$' etcetera
# The following zone is used by tzcode functions like gmtime,
# which load the "UTC" file to handle seconds properly.
Zone Etc/UTC 0 - UTC
The other two have a certain semantic difference, in that “Etc/UTC” would follow DST rules (if only “UTC” were the name of a normal time zone that had any), while “UTC+00:00” makes it clear that DST shall not apply.
@JoB, in which case, I believe that that distinction should be communicated to the user, rather than there be multiple apparently duplicate timezones, when they’re not.
Consequently, I would change this so that we would:
Hide:
Rename:
Make the offset configurable, so that we don’t have 13 entries for both GMT and UTC each, and so that we can use negative offsets too.
Merely because we ultimately acquire the timezones from IANA doesn’t restrict how we organize and hide them subsequently.
Are you absolutely sure that no one is using these? Where “no one” should include NASA for example and every linux powered device currently in space 
I just learned (google told me) that Zulu time “is used in the military and navigation for timekeeping purposes to avert confusion when coordinating with countries using other time standards.”
You have not noticed that I retained UTC in the subsequent paragraph:
Regardless, I’m solely referring to hiding these entries from the GUI - not modifying the underlying library providing this, if one exists.
That would negate the aforereferenced entries existent solely for backward compatibility. Why do "UTC+00:00", "UTC", and "Etc/UTC" all exist as options in the default Clock plasmoid? - #4 by JoB explains this.
They’re referring to UTC (ISO 8601 timezone Z). I was a NATO STANAG 2116 OR-2 in 2022. Read Zulu and UTC: the story behind aviation's time zone | Flightradar24 Blog. Zulu time uses UTC+00:00 because it’s the international default fallback when none exists.
Thanks for the link! I read there the following “Many aviators refer to it as Zulu” which means that some entities are still using it. Right?
So you can’t just hide it and call it a day. You need to explain to entities that from now on they need to choose something else.
Anyway… what I’m trying to say is that we can’t really just hide these which I guess exist in IANA’s database for some purpose, even if that purpose is just politics.
@jsalatas, they’re not using Zulu time. They’re using UTC, but erroneously refer to it as Zulu time, because solely region-based time pickers list Zulu time in lieu of a UTC offset despite utilizing UTC offsets in their code.
Having Zulu be retained is sensical because it is used by the Zulu people (despite not being attributable to a specific region due to the Zulus’ constant movement).
OK! in any case I believe that the right place to discuss this is the IANA’s tz mailing list and I also believe that it will cause trouble and confusion if KDE was deliberately hiding some of these timezones in some places.
@jsalatas, this isn’t for IANA, unfortunately, because this is an issue arising from duplicates existing for programmatic backward compatibility being exposed to users of a GUI.
Regardless, I hate mailing lists - I can’t subscribe specifically to the threads I care about, or be notified solely when my e-mail address is referenced. Forums are better for people solely interested in specific topics.
I’m solely referring to hiding these entries from the GUI - not modifying the underlying library providing this, if one exists.
Well, it would also necessitate that the KDE devs are willing to maintain a repo / translation table of their own, through whatever complications may arise later. As an example serving simultaneously as a pro and a con, IANA intends to keep a record of historic differences as well, so besides “Europe/Berlin” a.k.a. “most of Germany”, there also is a “Europe/Busingen”, because
# Büsingen <http://www.buesingen.de>, surrounded by the Swiss canton
# Schaffhausen, did not start observing DST in 1980 as the rest of DE
# (West Germany at that time) and DD (East Germany at that time) did.
which is of no interest to anyone who wants to calibrate his computer’s clock right now and for the foreseeable future, of course. But that doesn’t mean that the KDE devs would be any more interested in dealing with it just to have it special-cased out of your sight …
(And then the next thing that’ll happen is that people will ask to be allowed to find Europe/Berlin a.k.a. CE(S)T by typing in “Mitteleuropäische Sommerzeit” (our DST’s proper name per the governing national legalese, the ZeitG) or MESZ.)
They’re using UTC, but erroneously refer to it as Zulu time
If you think that’s bad, let’s talk about how GMT used to be a sidereal (i.e., observation-of-the-Sun-derived, thus necessarily DST-free) timescale, and wound up the name of the non-DST half of the UK’s standard technical (UTC-based) timescale today …
(Yes, that means that, depending on the accuracy you want, UTC and GMT may not be the same timescale.)
@JoB,
Indeed, I frequently spend a lot of time convincing developers that GMT and UTC are not identical. They… rarely believe me.
Surely they could merely transform it after it’s downloaded, before it enters the local database.
What about making the top half of the list preferred timezones (like existing, unduplicated, etc ones), and the second half de exotic ones. That way most of the people see a nice list with timezones (top half), while the 2nd half of the list to searched for the more exotic ones.
The other option is of course, to add a configuration button that shows more or less entries (default a short list, enabled all entries).
@radoeka, what would be considered “Exotic” or not seems like an arbitrary designation. It’s a bit like what https://www.reddit.com/r/kde/comments/6yf4ae/comment/dmn811g/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button describes.