Soren Stoutner <[email protected]> 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. > 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. -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
