Change:
stdenv.mkDerivation rec { pname = "tzdata"; <del> version = "2023b"; </del> <ins> version = "2023a"; </ins> srcs = [ (fetchurl { url = "https://data.iana.org/time-zones/releases/tzdata${version}.tar.gz"; <del> hash = "sha256-m3j9Jk+VYR/ph6lXIUVs1arJ9V5pFb5KnKKZe8fODmw="; </del> <ins> hash = "sha256-oqJ+23r1o4TPzv2une+tan7SPz8s/a89U5TB6CmXELw="; </ins> }) (fetchurl { url = "https://data.iana.org/time-zones/releases/tzcode${version}.tar.gz"; <del> hash = "sha256-EVSC47pm3LZRyI8s2nnFcQNqz5tjhzF41qBELNO+E9I="; </del> <ins> hash = "sha256-bczNJqE6S3HFPlc6C/MrmN5GeqMxa4Lf0l//22yfxGo="; </ins> }) ];

Discussion:
There is confusion about the recently announced daylight savings time changes in Lebanon. We have the latest tzdata- with the contested DST postponing in staging () and staging-22.11 (). We should ensure that it does not reach the master/release-22.11 branches until there is clarification from upstream (and Lebanon). Upstream I'm not sure what exactly to do. Either revert the commits to prevent them from reaching master/release-22.11, or just make sure staging/staging-22.11 don't get merged into the -next branches as long as the DST situation is unclear. tzdata- was regularly on Wednesday 2023-03-22. On Thursday, the Lebanese government announced that the spring forward planned for midnight between Saturday/Sunday 2023-03-25/26 will be postponed to April. Upstream on Friday 2023-03-24 to reflect this change. However, the decision to delay DST is in Lebanon as many institutions (banks, universities, ...) couldn't implement it in time. (merged the PRs)
Neither have made it to staging-next yet (see and ), so we've still got time. Also, why is this labeled with ? :eyes:
That's why I wrote "just make sure staging/staging-22.11 don't get merged into the -next branches as long as the DST situation is unclear.". At the moment everything is still not bad, but we should e.g. not blindly proceed with the next staging-next cycles today (or the coming days, depending on how long it takes to clarify the DST situation). tzdata is usually released with elevated priority, since it affects time and how time is displayed. This issue intends to raise awareness and prevent the branches to reach *-next. If you think it is mislabeled, you can of course remove it.
I do think we should defer to whatever upstream decides. And, as op noted, in Paul Eggert suggests sticking with for now, given that the only change in affects Lebanon and the change is contested.
Since this seems to be the only change in , a revert is a good option
Feel free to open a revert referencing the email linked above. I tried to push one to a branch, but github seems to be having some issues rn: Enumerating objects: 13, done.

Counting objects: 100% (13/13), done. Delta compression using up to 12 threads Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 724 bytes | 724.00 KiB/s, done. Total 7 (delta 6), reused 1 (delta 0), pack-reused 0 remote: Resolving deltas: 100% (6/6), completed with 6 local objects. remote: fatal error in commit_refs To ! [remote rejected] dwn/tzdata -dwn/tzdata (failure) error: failed to push some refs to ''
(Yes, even commenting often shows errors for me now.)