On Thursday, October 2, 2025 10:17:17 AM Mountain Standard Time Russ Allbery wrote: > Soren Stoutner <soren@debian.org> writes: > > The error message in my original email demonstrates that tzlocal does not > > consider GMT+12 to be a valid timezone format. > > That's because the purpose of tzlocal (according to its PyPI page; I hope > I have the right piece of software) is to find the corresponding tz > database file for the local time zone. GMT+12 does not *have* a tz > database file, so it is correct for tzlocal to return some sort of failure > in this case. I would argue that's indeed something for which the package > should have a test. :) The test suite should also be prepared for the case > where the local system is using a POSIX time zone rule and not a tz file > path. > > GMT+12 is a valid time zone, simply one outside of the range of zones for > which tzlocal was intended to work, since it is irrelevant to the purpose > of that software package. Packages that use tzlocal should be prepared to > deal with time zones of this type, since they are valid UNIX time zones. > > > This is one of the reasons why the Continent/City (zoneinfo) syntax is > > recommended and the GMT+12 syntax has been deprecated. > > GMT+12 has not been deprecated; it's required by POSIX. See tzset(3), > which documents both mechanisms for specifying a time zone. > > Using POSIX syntax to specify legally-created time zones for specific > geographic locations in the world is discouraged, which is not the same > thing as deprecated, because governments keep changing things about time > zones and, when looking at historical dates, generally applications want > to know what local time inhabitants of that area used at the time. This is > only possible with a file of historical rules; the POSIX syntax cannot > represent this. Therefore, for time zones reflecting a specific community > of people, the POSIX syntax is not recommended. > > None of this applies to fixed-offset time zones, for which the POSIX > syntax is simple and entirely sufficient, and which do not have those > concerns. This time zone was not intended to refer to a specific community > of people, only to a point in time zone space. That's often valuable to do > for various reasons such as boundary condition testing. In those cases, > you generally *do not want* the time zone to be affected by legal or > historical changes, which may break the test conditions that you're trying > to create. Thank you for that background. > > 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. > > I believe this request should be respectfully declined because it's based > on a misunderstanding of time zone specifications. This is a problem > specific to the software that you are testing and should not force > infrastructure changes. > > Source: I have been following the tz mailing list and time zone rule > maintenance for about 30 years. Can you think of any way that using the Etc/GMT+12 and Etc/GMT-14 syntax would cause any *problems*? For example, is there some essential feature of reproducible builds that I am not aware of that doesn’t know how to parse zoneinfo data? If not, what would your objection be to having the reproducible builds ecosystem use the zoneinfo format? As far as I can tell, doing so would cause no problems and would improve reproducible builds by allowing tests like these to succeed. (So far I have receive several responses objecting to change, but no explanation of any reason *why* there shouldn’t be a change.) -- Soren Stoutner soren@debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part.