On 2025-10-08, Soren Stoutner wrote: > 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?
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
signature.asc
Description: PGP signature
