Soren Stoutner <[email protected]> writes: > On Thursday, October 2, 2025 10:33:36 AM Mountain Standard Time Russ Allbery > wrote:
>> The point of using GMT+12 and GMT-12 is that they keep the same >> (incorrect, but it doesn't really matter for this purpose) time zone >> abbreviation for reproducibility testing: >> % env TZ=GMT+12 date >> Thu Oct 2 05:32:09 AM GMT 2025 >> % env TZ=GMT-12 date >> Fri Oct 3 05:32:12 AM GMT 2025 >> Otherwise, you may get spurious reproducibility failures due to the >> changed time zone abbreviation. >> I don't believe there is a mechanism to force the same time zone >> abbreviation other than usig POSIX rule-based zones. > Isn’t the exact *purpose* of the reproducible builds project to make > sure that software compiles the same even when things like time zone > abbreviations are different? So, if this produces failures, aren’t these > the exact types of failures the reproducible builds project is trying to > uncover? I have no idea; the reproducible build team should make that call. I could see an argument either way depending on what the definition of reproducibility is. If they do indeed want to fail reproducibility if the time zone abbreviation changes, then I agree, they should use Etc/GMT+12 and Etc/GMT-12 instead, because that will achieve that goal. So far as I know, the two benefits to using the POSIX rule-based time zones over those Etc/* zones are to force the abbreviation to stay the same and to not require that tzdata be installed, and I don't *think* the latter is a valid build target for Debian (although tzdata is only required, not essential, so maybe that's also a consideration?). -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
