On Thu, 02 Oct 2025 at 07:02:49 -0700, Soren Stoutner wrote:
On Thursday, October 2, 2025 12:08:28 AM Mountain Standard Time Holger Levsen wrote:On Wed, Oct 01, 2025 at 04:20:16PM -0700, 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 theymodify> the timezone in the build environment using syntax like GMT+12 instead of > the > Continent/City syntax.
This seems like a missing feature in the code under test or one of its dependencies, to be honest, and I think it should be reported as a (non-RC) bug. GMT+12 is a valid (if unusual) time zone, and most geographic time zones have a clock change twice a year, which sometimes makes it desirable to use a non-geographic time zone like Etc/UTC.
a.) set the timezone in the test (not 100% you can do this)
This should certainly be possible, TZ is just an environment variable like any other.
This is why I asked the question about whether using the GMT+12 syntax catches some actual problem that using Continent/City does not.
I believe reproducible-builds intentionally uses the most extreme possible time zones (GMT+12 and GMT-12) to maximize the chance that build 1 and build 2 would get different results for something like:
echo "#define BUILDDATE \"$(date '+%Y-m-d')\"" > builddate.h
which is a source of non-reproducibility, even if the `date` command was
modified to use $SOURCE_DATE_EPOCH if set, because it's printing the
date in the local time zone. For example compare:
TZ=GMT+12 date -d '2025-10-02T15:26:00Z' '+%Y-%m-%d'
TZ=GMT-12 date -d '2025-10-02T15:26:00Z' '+%Y-%m-%d'
(this is the currently recommended way to set timezones in Linux)
"Currently recommended" prompts the obvious question: recommended by who?
smcv