From: soren@debian.org 
  
 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 
 [continued in next message] 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)