Permanent "Loading ..." state on Fedora 39

[DmitryBurstein]

I just found and installed your version of the extension - brutally overwriting all the original files in my home directory. Gnome 45 successfully loads it, but it never displays any actual weather data, being permanently stuck in loading stage. Manually clicking the reload button doesn't help.
Checking the system journal reveals an only openweather-related error "JS ERROR: Error: GSettings key clock-format not found in schema org.gnome.shell.extensions.openweather"

[nnrudakov]

Not only on Feroda. Ubuntu has the same error too. I think it depends on system clock format.

WA I replaced here return value to "24h" and relogin.

[ferdnyc]

@nnrudakov @DmitryBurstein

I think it depends on system clock format.

You're probably correct, though that dependency is only accidental.

@toppk added a settings key "clock-format" to the schema, to replace the old hard-coded "24h" return value that skrewball had the _clockFormat property returning:

3e69bf8c

     get _clockFormat() {
-      return "24h";
-      //return SETTINGS.get_string("clock-format");
+      return SETTINGS.get_string("clock-format");
     }

There are three places where the code checks whether _clockFormat === "24h", and processes date/time data differently. Here's one example:

gnome-shell-extension-openweather/src/openweathermap.js

Lines 429 to 438 in 9117377

	if (this._clockFormat === "24h") {
	forecastTime = forecastTime.toLocaleTimeString([this.locale], {
	hour12: false,
	});
	forecastTime = forecastTime.substring(0, forecastTime.length - 3);
	} else {
	forecastTime = forecastTime.toLocaleTimeString([this.locale], {
	hour: "numeric",
	});
	}

In the past, the first branch of the if() would always be taken, because "24h" was hardcoded as the only possible value for the clock format.

But when @toppk added clock-format to the settings schema, he accidentally made the default value (the only value, because there's no UI to change it) "24hr", instead of "24h":

gnome-shell-extension-openweather/schemas/org.gnome.shell.extensions.openweather.gschema.xml

Lines 166 to 169 in 9117377

	<key type="s" name="clock-format">
	<default>'24hr'</default>
	<summary>Time format for hours</summary>
	</key>

That means that this._clockFormat === "24h" will never be true, and the code will always follow the second branch of the if(). And that code is basically untested, because even though it was present in skrewball's version of the extension, it could never be run.

(And, looking at it, because it doesn't set hour12 one way or the other, the time formatting will depend on the default format for the current locale — which is why some people are seeing problems, and others aren't.)

This:

forecastTime.toLocaleTimeString([this.locale], { hour12: false });

will always come out as something like "22:04:17", in any locale. (Which the code then trimmed to "22:04" using that .substring() call on the next line.)

but this:

forecastTime.toLocaleTimeString([this.locale], { hour: "numeric" });

will come out for me as "10 PM" (just the hour, because when you specify specific components they're the only ones you get), because I live in a 12-hour locale. But for someone else in a 24-hour locale, it will come out as just "22" and nothing else.

I suspect there's code in the extension that can't deal with the ambiguity of getting either "10 PM" or "22" for time values, where it used to always get "22:04". (Or similar for one of the other instances where the code is dependent on whether clock-format is "24h").