Re: Question about reproducibility tests timezone format
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.
> 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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: