GNOME Bugzilla – Bug 692243
Add UTC location to gnome-clocks
Last modified: 2017-12-17 13:56:05 UTC
Please add a UTC location to the set of locales for gnome-clocks. This would be useful for many purposes; ham radio is one of those purposes. Thanks! Erik Beck traderbeckola@tahoma.com
I second this request. One of the purposes of gnome-clocks is the collaboration in a multi-national team. I have many world clocks defined to see the current local time of my remote colleagues. But all our meetings and events are always defined in UTC and gnome-clocks offers no easy way to discover the current time in UTC. I don't want to remember my UTC offset. I want gnome-clocks to help me instead.
*** Bug 695223 has been marked as a duplicate of this bug. ***
I agree that we should add a way to have an UTC clock. Right now the limitation was due to the choice of using libgweather to get the location (the entry widget is directly provided by this library). Using this library allowed us to get this implemented quickly, but maybe it is time to revisit this choice...
London recently went/started on Daylight Savings Time I REALLY DON'T LIKE BEING AN HOUR LATE! (or early come this fall from UTC / ZULU). ... So could someone please raise the priority of this to urgent? :)
Created attachment 243424 [details] [review] Add UTC to top of libgweather/data/Locations.xml.in
*** Bug 699080 has been marked as a duplicate of this bug. ***
I do not think adding a fake location to the gweather database is the way to go... anyway you should maybe file a separate bug against libgweather. I'd like to have our own entry (maybe inline with a gtksearchentry + a listbox), but that is blocked by https://bugzilla.gnome.org/show_bug.cgi?id=734878
Can we improve the priority of this bz, it should be considered high priority. Please, either add UTC to the library Gnome uses, or add UTC (and other arbitrary timezone offsets) alongside the library, or whatever.
Following the duped bug it looks like it's dependent on bug https://bugzilla.gnome.org/show_bug.cgi?id=734878
Hello, To jump on the band wagon: I also think this is essential. Trying out the clocks app today and not being able to get the UTC time kind of defeated the purpose of the world clocks functionality for me. My use case: I work with a whole bunch of SQL databases in which dates are stored in UTC time. Having the current UTC time readily available from the Gnome shell calendar widget would be super convenient.
lol, 2 years later and I can't add UTC/GMT to world clocks. Maybe you shouldn't have included this app in the official release, it's clearly not ready.
If the functionality of UTC is essential to you, you can use the workaround to add Reykjavik/Iceland for now. It always stay on UTC + 0h, and does not have a system of daylight saving, so it will stay the same all year around. http://www.timetemperature.com/europe/iceland_time_zone.shtml
It would sure be nice to get this long-standing bug squashed. I see two main options, which could both be pursued on different time scales: 1) Add UTC as a location to libgweather. While UTC is a time standard, not a location, it should be easy to add it anyway. If not, how about putting in the location of the original Royal Observatory in Greenwich, England (now part of London) that defined the prime meridian and Greenwich Mean Time, AKA UTC. GPS coordinates are (per wikipedia): 51.48 degrees N; 0.00000 degrees E. Someone tried to submit a patch for this bug eons ago, but it didn't take. See bug history. 2) Rewrite gnome clocks to use the tz database (time zone database or zoneinfo database) shipped with every Linux system. This would take more work, but would really link to a well-maintained source of time zone data. In the interim, I am using Andreas' suggestion of using Reykjavik in lieu of UTC, and it works OK, but I think this issue deserves a deliberative and more persistent fix. Thanks, Erik
See response to notion of adding UTC to libgweather. Bug 753699
*** Bug 749945 has been marked as a duplicate of this bug. ***
Just discovered tzclock (tzclock.org). Looks like it will meet my needs.
*** Bug 763714 has been marked as a duplicate of this bug. ***
This request is already open for 3 years, will it ever be honored?
(In reply to keesdejong+bugs from comment #18) > This request is already open for 3 years, will it ever be honored? The keyword here is 'request'. The next thing to realize is that even you can 'honor' it. :)
A comment from bug #699080: FWIW there is nothing special about Pacific Daylight Time; it's just the timezone one hour behind Mountain Daylight Time and one hour ahead of Pacific Standard Time. I'm not opposed to adding support for arbitrary timezones, distinct from any city, but you'd have to think about how to do this in a user-friendly way. We should not expect users to understand the distinction between PST and PDT, we should absolutely never display PST when we really mean PDT, and we probably can't automatically switch between the two because different countries (and Arizona...) switch timezones on different dates. In contrast, if you know PST/PDT is San Francisco or LA or Seattle, Clocks can just show you the right time without worry about complicated timezone nonsense. (In reply to Mike A Kouklis from comment #4) > London recently went/started on Daylight Savings Time I REALLY DON'T LIKE > BEING AN HOUR LATE! (or early come this fall from UTC / ZULU). > ... > So could someone please raise the priority of this to urgent? :) Yeah, so the thing is, adding a UTC item might make this even MORE confusing, because people might assume UTC == London time... it just requires some thought how to do this in a user-friendly way, to avoid people making the same mistake as you. I really DO want the ability to add a UTC clock -- it's very frustrating to not have one right now -- but that's something we should keep in mind.
Yes, UTC should be a distinct listing that the user can choose. Ubuntu offers this. So should Gnome.
*** Bug 780890 has been marked as a duplicate of this bug. ***
*** Bug 780891 has been marked as a duplicate of this bug. ***
*** Bug 784122 has been marked as a duplicate of this bug. ***
These days (>= 3.22.x) typing "utc" or "gmt" leads to multiple entries showing up.
But that's UTC Malaysia, UTC France, GMT Chile etc, right? None of those are Coordinated Universal Time as far as I can see.
(In reply to Andreas Nilsson from comment #26) > But that's UTC Malaysia, UTC France, GMT Chile etc, right? > None of those are Coordinated Universal Time as far as I can see. Yes. I hadn't tried adding one before.
OK this is now a really old bug. time and weather are not linked in any way. please use the standard tzdata for time and let the weather use the weather libraries. I really want to have utc times in the gnome clocks so that i can easily see various utc clocks compared my current timezone easily.
(In reply to Michael Hoffman from comment #28) > OK this is now a really old bug. time and weather are not linked in any > way. please use the standard tzdata for time and let the weather use the > weather libraries. I really want to have utc times in the gnome clocks so > that i can easily see various utc clocks compared my current timezone easily. tzdata doesn't cover even half the locations we can have people search for when adding Clocks (there's Amsterdam, but The Hague is the capital and isn't there!), and doesn't name any countries either. We can't use tzdata. libgweather has all that information already in its database. If it was a good way to fix the problem, I'm sure somebody would have done it that way already. It's not though.
(In reply to Bastien Nocera from comment #29) > tzdata doesn't cover even half the locations we can have people search for > when adding Clocks (there's Amsterdam, but The Hague is the capital and > isn't there!) Just an FYI, Amsterdam is the capital of The Netherlands. So please don't change this detail :)
I don't see this as depending on #753699. I think the principle problem is as Erik Beck said - conflating timezones and weather is not correct. It might be helpful to back location data onto timezones, but we should really be looking at /usr/share/zoneinfo first and then listing libgweather results at the bottom.
Sorry, I meant Giovanni Campagna, not Erik Beck.
(In reply to tudor from comment #31) > I don't see this as depending on #753699. I think the principle problem is > as Erik Beck said - conflating timezones and weather is not correct. Once you've created a database that has 1) cities 2) time zone information for each one, 3) physical location, you end up with pretty much libgweather's database. > It > might be helpful to back location data onto timezones, but we should really > be looking at /usr/share/zoneinfo first and then listing libgweather results > at the bottom. Then we couldn't look for cities. I'm not sure that's going forward.
(In reply to Bastien Nocera from comment #33) > (In reply to tudor from comment #31) > > I don't see this as depending on #753699. I think the principle problem is > > as Erik Beck said - conflating timezones and weather is not correct. > > Once you've created a database that has 1) cities 2) time zone information > for each one, 3) physical location, you end up with pretty much > libgweather's database. > > > It > > might be helpful to back location data onto timezones, but we should really > > be looking at /usr/share/zoneinfo first and then listing libgweather results > > at the bottom. > > Then we couldn't look for cities. I'm not sure that's going forward. You misunderstand me. /usr/share/zoneinfo does contain some cities, but principally it has all timezones, so we can do both /usr/share/zoneinfo and **then** libgweather results. That way, if there is no timezone with that name, then cities are still listed.
(In reply to tudor from comment #34) > (In reply to Bastien Nocera from comment #33) > > (In reply to tudor from comment #31) > > > I don't see this as depending on #753699. I think the principle problem is > > > as Erik Beck said - conflating timezones and weather is not correct. > > > > Once you've created a database that has 1) cities 2) time zone information > > for each one, 3) physical location, you end up with pretty much > > libgweather's database. > > > > > It > > > might be helpful to back location data onto timezones, but we should really > > > be looking at /usr/share/zoneinfo first and then listing libgweather results > > > at the bottom. > > > > Then we couldn't look for cities. I'm not sure that's going forward. > > You misunderstand me. /usr/share/zoneinfo does contain some cities, but > principally it has all timezones, so we can do both /usr/share/zoneinfo and > **then** libgweather results. That way, if there is no timezone with that > name, then cities are still listed. The data in /usr/share/zoneinfo is unusable in a UI. It's not translated, has tons more dubious data than we would ever want (look at the "PST8PDT", "posixrules", or "NZ-CHAT" timezones), lists every single UTC offset which we wouldn't want. It's unusable data.
Created attachment 364737 [details] [review] Add UTC Clock Requires a newer libgweather, and some careful stepping around the fact that there is no weather info for the UTC timezone.
Review of attachment 364737 [details] [review]: Thanks for working on the Bastien! If it requires a new libgweather can you bump it in meson.build? Or do you mean that UTC works with newer libgweather, but falls back nicely to the old behaviour with an older version? Either way, if you tested go ahead and push it. (One cosmetic comment below that would be great to amend before pushing) ::: src/world.vala @@ -78,3 +78,3 @@ public bool is_daytime { get { - return weather_info.is_daytime (); + if (weather_info != null) cosmetic: we use {} also for 1-line if (same also for the places below)
Created attachment 364904 [details] [review] Add UTC Clock Requires a newer libgweather, and some careful stepping around the fact that there is no weather info for the UTC timezone.
Review of attachment 364904 [details] [review]: Looking from the phone so I might be looking at the wrong thing... As far as I can see the small cosmetic comments for the previous patch still apply. Feel free to amend and then push
(In reply to Paolo Borelli from comment #39) > Review of attachment 364904 [details] [review] [review]: > > Looking from the phone so I might be looking at the wrong thing... > > As far as I can see the small cosmetic comments for the previous patch still > apply. It's the same patch updated for the API changes I made to the WIP libgweather patch. It's waiting on Giovanni to review. Let me attach a new version with the nits fixed.
Created attachment 364951 [details] [review] Add UTC Clock Requires a newer libgweather, and some careful stepping around the fact that there is no weather info for the UTC timezone.
Created attachment 365079 [details] [review] Add UTC and "Anywhere on Earth" clocks Requires a newer libgweather, and some careful stepping around the fact that there is no weather info for timezones.
Attachment 365079 [details] pushed as d97a965 - Add UTC and "Anywhere on Earth" clocks
Thank you all so much, especially Bastien! Gracias, Danke! Merci beaucoup!