Closed havardAasen closed 1 year ago
@havardAasen I'll look at this when I get a chance, but I believe the issue is that I only have the one doc_date
value cached when generating a PS or PDF file. Using a separate UTC value is a possibility...
I will note, however, that any document that is generated with a date or time in the header or footer will still end up using the local timezone. Shouldn't be an issue for the HTMLDOC users manual but my proposed fix won't solve your issue with HTMLDOC as a build tool. There you should probably force the timezone setting in the environment (probably to UTC).
@michaelrsweet, reading you previous comment, it seems you have a solution in mind?
The only thing I can think of is in the direction of a command-line argument like --utc
, and then just toggle localtime_r
and gmtime_r
. If not entirely elegant, it's at least simple.
@havardAasen Yes, set the "TZ" environment variable to "UTC" or "GMT" to get dates and times in UTC. Like I said, this will affect the dates and times in headers/footers as well.
[master 8d16a96] Use UTC for PS/PDF metadata (Issue #490)
Changes only affect the metadata. If you put date/time information in the header/footer then you need to set the timezone prior to running htmldoc in order to force UTC vs. local time.
After the change from
gmtime_r
tolocaltime_r
in a67e9ccfe20756fdda7ea7b50119d36ac8ffac0b, the build became unreproducible. Where it's the timezone that makes the difference. This is in part a regression from #310.When we build this package in Debian, we create the documentation at the same time, with HTMLDOC. This means that with version 1.9.16, the
CreationDate
ofpdf
andps
documents, will change depending on timezone.How important is the need to use
localtime_r
? I noticed #485, which makes me believe this is a wanted feature. Also, was the change tolocaltime_r
needed for #472 to be fully functional?