On Thursday, October 2, 2025 7:41:13 AM Mountain Standard Time Simon McVittie wrote: > 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. The error message in my original email demonstrates that tzlocal does not consider GMT+12 to be a valid timezone format. zoneinfo._common.ZoneInfoNotFoundError: 'tzlocal() does not support non- zoneinfo timezones like GMT+12. \nPlease use a timezone in the form of Continent/City’ As you point out, most timezones have a clock change twice a year. Using the Continent/City (zoneinfo) syntax encapsulates this information in a way that GMT+12 does not. For example, I live in the America/Phoenix timezone, which does not change and is always GMT-7. I used to live in the America/Boise timezone, which switches between GMT-7 and GMT-6. Additionally, the Continent/City syntax informs the computer on which dates the time switches, which might not always be the same depending on jurisdiction. This is one of the reasons why the Continent/City (zoneinfo) syntax is recommended and the GMT+12 syntax has been deprecated. Some further background can be found at: https://en.wikipedia.org/wiki/Tz_database > 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' There is no reason I can think of that this couldn’t be replicated using the Continent/City (zoneinfo) timezone syntax. For example, they could easily use Etc/GMT-12 and Etc/GMT+12. Note that the signs are intentionally inverted, so that Etc/GMT-12 is GMT+12. "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 In fact, Etc/GMT+12 and Etc/GMT-14 might even better exercise what reproducible builds wants to accomplish. https://en.wikipedia.org/wiki/List_of_tz_database_time_zones > >(this is the currently recommended way to set timezones in Linux) > > "Currently recommended" prompts the obvious question: recommended by who? By the Debian Installer among many other examples. This has been generally established for the entire industry by the IANA (Internet Assigned Numbers Authority) as described in the Wikipedia links above. So far, there have been three responses to my original email. None of them have described any benefit to using the GMT+12 syntax over the Continent/City (zoneinfo) syntax for reproducibility tests. I also can’t think of any disadvantage to using the Continent/City (zoneinfo) syntax, but I am open to there being some negative aspect of it that I have not yet considered. My assumption is that the reproducibility tests are simply using the GMT+12 syntax for historical reasons because that was what was common when they were originally setup and nobody has bothered to change it. I will wait several more days to see if anyone does know of some compelling reason why it needs to be GMT+12. If not, I will submit requests to Salsa CI and reproducible builds (and any other part of Debian’s infrastructure that anyone can think of that is still using the deprecated syntax) requesting they adjust to using the Continent/City (zoneinfo) syntax. -- Soren Stoutner soren@debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part.