Package: qhelpgenerator-qt5 Followup-For: Bug #1059631 X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
On Fri, 29 Dec 2023 15:30:58, I wrote: > 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. ... > 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. In hindsight: I think I've misunderstood some of the details here. If the root cause is indeed a non-UTC timezone on the last_modified object, then maybe it does in fact make sense to translate that object's value into UTC -- because that would mean that we the date-string we bind is always UTC-based, regardless of whether SOURCE_DATE_EPOCH is set. Related, though: I also don't yet understand why the date string that appears in the INSERT statement does not include a timezone offset (+1200, for example). My reading of the QT documentation[1] is that a timezone offset will be included in the formatted string for non-UTC date+time objects.. I'll do some more investigation. [1] - https://doc.qt.io/qt-5/qt.html#DateFormat-enum