As the go_bootstrap timezone tests already require disabling/patching, I'd rather don't revert that commit so we don't need to bother with them in the future.

As the go_bootstrap timezone tests already require disabling/patching, I'd rather don't revert that commit so we don't need to bother with them in the future.

It was valuable because it helped change my mind, letting me find the root cause and a better solution. That doesn't necessarily mean it will be valuable in the future though.
I'm leaning towards keeping the test, but I don't feel strongly about it.

We already disable lots of tests for the go packages, I really don't see the benefit in keeping this one.

Sure enough. You're the go maintainer, not me :)

How wide are the breakages? Can we do it on staging-next?

I don't know how wide. It only shows when you miss an appointment. I don't know which time zones and time ranges are affected. libical apps seem to be affected, possibly more. It'd take considerable effort to figure that out, because test suites may or may not detect the problem.

How wide are the breakages? Can we do it on staging-next?

Channel blocking. https://hydra.nixos.org/build/129869656

If reverting to the old format while keeping the latest version of tzdata is enough, then let's do that. Wel'll need to undo the disabling of the tests as well then and this needs to target staging-next.

@GrahamcOfBorg build libical

Is it possible there are other regressions for the latest tzdata update?

@doronbehar is that master?

I don't know the exact details of the format change, but a certain section of data is missing in the "slim" format. It's supposedly redundant, but some programs clearly still depend on it. The wrong UTC+00 is probably caused by that missing data?

@roberth that's from the current latest nixos-unstable channel, which doesn't include the change. I'd have tested this change on my fork, but I didn't merge it since it seems it'd cause tons of rebuilds :/.

I also noticed that manually setting a certain time or using a different time zone, keeps reverting me back to the old time zone.

You can use staging-next branch which contains the fix and is mostly built.

I can reproduce this in gnome-control-center in staging-next too. Weirdly, when I click on some location on map, it briefly shows the correct timezone before changing to UTC. And if I click the map second time without moving cursor, it reverts to the correct timezone.

Possibly https://gitlab.gnome.org/GNOME/glib/-/issues/2215

Then maybe we should patch glib with https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1705 ?

There has been a new glib release since, currently testing

diff --git a/pkgs/desktops/gnome-3/core/gnome-control-center/default.nix b/pkgs/desktops/gnome-3/core/gnome-control-center/default.nix
index 1300f7a7503..0695aeb2cb8 100644
--- a/pkgs/desktops/gnome-3/core/gnome-control-center/default.nix
+++ b/pkgs/desktops/gnome-3/core/gnome-control-center/default.nix
@@ -94,6 +94,14 @@ stdenv.mkDerivation rec {
   ];
 
   buildInputs = [
+    (glib.overrideAttrs (attrs: rec {
+      inherit (attrs) pname;
+      version = "2.66.2";
+      src = fetchurl {
+        url = "mirror://gnome/sources/glib/${stdenv.lib.versions.majorMinor version}/${pname}-${version}.tar.xz";
+        sha256 = "1i0pd8y6xz64qlzfj73wxyqp0x7x9j6mwf4gj6ggil4d9vnhnfgc";
+      };
+    }))
     accountsservice
     adwaita-icon-theme
     cheese
@@ -103,7 +111,6 @@ stdenv.mkDerivation rec {
     colord-gtk
     fontconfig
     gdk-pixbuf
-    glib
     glib-networking
     gnome-bluetooth
     gnome-desktop
diff --git a/pkgs/desktops/gnome-3/core/gnome-settings-daemon/default.nix b/pkgs/desktops/gnome-3/core/gnome-settings-daemon/default.nix
index 3c039bc6310..cc21910d3d6 100644
--- a/pkgs/desktops/gnome-3/core/gnome-settings-daemon/default.nix
+++ b/pkgs/desktops/gnome-3/core/gnome-settings-daemon/default.nix
@@ -76,8 +76,15 @@ stdenv.mkDerivation rec {
   ];
 
   buildInputs = [
+    (glib.overrideAttrs (attrs: rec {
+      inherit (attrs) pname;
+      version = "2.66.2";
+      src = fetchurl {
+        url = "mirror://gnome/sources/glib/${stdenv.lib.versions.majorMinor version}/${pname}-${version}.tar.xz";
+        sha256 = "1i0pd8y6xz64qlzfj73wxyqp0x7x9j6mwf4gj6ggil4d9vnhnfgc";
+      };
+    }))
     gtk3
-    glib
     gsettings-desktop-schemas
     modemmanager
     networkmanager

Yes, that seems to fix it.

configuration.nix workaround for those who don’t want to wait for their entire system to rebuild:

{
  environment.etc.zoneinfo.source = lib.mkForce "${
      pkgs.tzdata.overrideAttrs (old: {
        makeFlags = old.makeFlags
          ++ [ ''CFLAGS+=-DZIC_BLOAT_DEFAULT=\"fat\"'' ];
      })
    }/share/zoneinfo";
}

configuration.nix workaround for those who don’t want to wait for their entire system to rebuild:

{
  environment.etc.zoneinfo.source = lib.mkForce "${
      pkgs.tzdata.overrideAttrs (old: {
        makeFlags = old.makeFlags
          ++ [ ''CFLAGS+=-DZIC_BLOAT_DEFAULT=\"fat\"'' ];
      })
    }/share/zoneinfo";
}

That fixed it for me, Thanks!