I maintain pyinstaller-hooks-contrib, which includes a test (run during build and in autopkgtests) that parses the system timezone. This test currently fails Salsa CI reprotest and other reproducibility tests because they modify the timezone in the build environment using syntax like GMT+12 instead of the Continent/City (zoneinfo) syntax. zoneinfo._common.ZoneInfoNotFoundError: 'tzlocal() does not support non- zoneinfo timezones like GMT+12. Please use a timezone in the form of Continent/City’ https://salsa.debian.org/python-team/packages/pyinstaller-hooks-contrib/-/jobs/8382666#L6097 I can see the wisdom in having reproducibility tests check to make sure that packages build correctly in different timezones. My question is: do we gain anything by using the GMT+12 syntax, or could we achieve the same results by varying the timezone using the Continent/City format? This was discussed on debian-devel in the thread beginning at: https://lists.debian.org/debian-devel/2025/10/msg00006.html Etc/GMT+12 and Etc/GMT-14 would provide the largest offset (note the difference in the numbers, with the positive offset going up to 12 and the negative offset going up to 14). https://en.wikipedia.org/wiki/List_of_tz_database_time_zones#List "The special area of "Etc" is used for some administrative zones, particularly for "Etc/UTC" which represents Coordinated Universal Time. In order to conform with the POSIX style, those zone names beginning with "Etc/GMT" have their sign reversed from the standard ISO 8601 convention. In the "Etc" area, zones west of GMT have a positive sign and those east have a negative sign in their name (e.g "Etc/GMT-14" is 14 hours ahead of GMT). https://en.wikipedia.org/wiki/Tz_database#Area
Hi! As mentioned on the salsa-ci MR at <https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/512>: As was mentioned on the list thread, this change would require for tzdata to be installed everywhere, otherwise the results are bogus (AFAIUI). On a system with tzdata installed: ,--- $ TZ=GMT+12 date -d '@2147483647' Mon Jan 18 15:14:07 GMT 2038 $ TZ=Etc/GMT+12 date -d '@2147483647' Mon Jan 18 15:14:07 -12 2038 `--- On a system without tzdata installed: ,--- $ TZ=GMT+12 date -d '@2147483647' Mon Jan 18 15:14:07 GMT 2038 $ TZ=Etc/GMT+12 date -d '@2147483647' Tue Jan 19 03:14:07 Etc 2038 `--- As such, I don't think this should be changed, and if the referenced package has a problem with this, its test suite should massage its environment so that it can test what it is supposed to be testing. Thanks, Guillem
We can test consitent timezones, rather than relying on timezones that may or may not have daylight savings time such that a package might build reproducibly with or without daylight savings time. Even if we can find sufficiently divergent timezones that happen to not have daylight savings time today, there is no guarantee that that a particular Continent/City will not institute daylight savings time at a later date, or even change timezone entirely. Using UTC offsets avoids all of that mess. It also allows us to make sure at least the day changes, by having offsets spanning over 24 hours (e.g. UTC+12 and UTC-14 ~= 26 hour time difference, and which is actually represented in the real world due to countries that span the international date line). If you need to, you can workaround this and disable the use of timezones in salsa-ci jobs where this breaks assumptions of the package, if the package cannot be fixed reasonably: https://salsa.debian.org/salsa-ci-team/pipeline/#customize-reprotest live well, vagrant
On Wednesday, October 8, 2025 2:15:53 PM Mountain Standard Time Vagrant Cascadian wrote: Using consistent and divergent timezones that do not implement daylight savings time is indeed an important consideration. I think that is fully addressed by using the Etc/GMT+12 and Etc/GMT-14 syntax. Please note, as described in the original bug report: “The special area of "Etc" is used for some administrative zones, particularly for "Etc/UTC" which represents Coordinated Universal Time. In order to conform with the POSIX style, those zone names beginning with "Etc/GMT" have their sign reversed from the standard ISO 8601 convention. In the "Etc" area, zones west of GMT have a positive sign and those east have a negative sign in their name (e.g "Etc/GMT-14" is 14 hours ahead of GMT).” https://en.wikipedia.org/wiki/Tz_database#Area There may be some great difficulty caused by making tzdata a dependency of reprotest. If there is I would be interested in know what it is. It should be noted that the reproducible builds project successfully builds this package. https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ pyinstaller-hooks-contrib.html My memory is that didn’t used to be the case. So, either my memory is wrong or reproducible builds recently started using the Continent/City (zoneinfo) syntax. In either case, I think it would be advantageous for reprotest (and the Salsa CI test that uses it) to mirror the behavior of reproducible builds.
Adding tzdata as a dependency to reprotest would not affect what gets installed in the chroots where the packages get built. Forcibly injecting that in the chroots would be wrong in so many ways, when we have made it possible to not need to have it installed in buildds (or as part of the build-essential transitive set) by default. Given that tzdata is not installed unless (build-)depended on explicitly, using the Continent/City notation seems wrong for the reproducible-builds to be setting it like that. But in any case if that package fails to build when the current timezone is set to a valid value that the package does not support, then that is definitely a bug in that package that should be fixed. Trying to force the build/test (or user) systems to use another format is not reasonable. I'll be failing a FTBFS bug against pyinstaller-hooks-contrib once I've confirmed it locally. Thanks, Guillem
control: severity -1 wishlist control: tags -1 wontfix thanks eeks. also its not acceptable to install tzdata everywhere because one package has problems... agreed, thanks.
On Thursday, October 9, 2025 12:00:09 AM Mountain Standard Time Guillem Jover wrote: tzdata builds wrong (zoneinfo) (and As noted earlier, it builds and tests fine in Debian’s official reproducible builds. I would assume that means that the tzdata package is installed and that the timezone modifications are done using the Continent/City (zoneinfo) syntax when reproducible builds are run. I was under the impression that reprotest desired to produce the same results as the official reproducible builds. Is that not correct?