Bug#1059631: qhelpgenerator-qt5: nearly-reproducible LastRegisterTime value in .qch files is not timezone-normalized
Package: qhelpgenerator-qt5
Followup-For: Bug #1059631
X-Debbugs-Cc: reproducible-bugs@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
Reply to: