Package: qhelpgenerator-qt5 Version: 5.15.2-3 Severity: wishlist User: reproducible-bui...@lists.alioth.debian.org Usertags: timezone X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Dear Maintainer, Looking at some recent Reproducible Build[1] test results[2] for the Debian openorienteering-mapper package, the LastRegisterTime value placed into the SettingsTable table in the .qch (sqlite3 db) file format can vary based on the build host's configuration. Inspecting the patch from #875847 and the values that appear in the diffoscope output from the build logs: the SOURCE_DATE_EPOCH value of the build is used, as expected, to improve the reproducibility of the build. It takes the value of the most recent Debian changelog entry. However: the patch mutates an existing QT QDateTime instance (last_modified) to store the seconds-since-epoch value -- without specifying a timezone for the value. I'm not 100% certain, but I think it's likely (given that the duration between the two timestamps that appear in the diffoscope output is 26 hours, equal to the local-time-difference between GMT-14 and GMT+12, the two build timezones) that the last_modified object remains timezone-relative in each build, and therefore emits differing LastRegisterTime values in ISO format. -INSERT INTO SettingsTable VALUES('LastRegisterTime','2021-12-27T21:45:41.000'); +INSERT INTO SettingsTable VALUES('LastRegisterTime','2021-12-28T23:45:41.000'); My sense is that the LastRegisterTime column value is probably intended to be stored in UTC; it may be sufficient to set the timezone of the last_modified instance to UTC -- making careful to ensure that it is indeed a _set_ timezone operation and not a _translate_ timezone operation. Regards, James [1] - https://reproducible-builds.org/ [2] - https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/arm64/diffoscope-results/openorienteering-mapper.html [3] - https://doc.qt.io/qt-5/qdatetime.html