I think I found one of the remaining places where timestamps were
sneaking into CreateDate when using fop to generate PDFs.

If this sounds familiar, that is because this is a follow-up to the
original bug which partially fixed the issues:

https://bugs.debian.org/978499

It has been nagging at me in the 5 or so years since; I think I finally
identified where in the code needs to be adjusted!

This patch is more of a proof-of-concept than a real patch, although it
did appear to fix the one remaining issue for the pam and treeview
packages.

diff --git a/fop-core/src/main/java/org/apache/fop/render/intermediate/IFRenderer.java b/fop-core/src/main/java/org/apache/fop/render/intermediate/IFRenderer.java
index 84e4e3a..a4d8d7c 100644
--- a/fop-core/src/main/java/org/apache/fop/render/intermediate/IFRenderer.java
+++ b/fop-core/src/main/java/org/apache/fop/render/intermediate/IFRenderer.java
@@ -544,7 +544,8 @@ public class IFRenderer extends AbstractPathOrientedRenderer {
         } else {
             xmpBasic.setCreatorTool(Version.getVersion());
         }
-        xmpBasic.setMetadataDate(new java.util.Date());
+        final Long sourcedate = (1000 * Long.parseLong("1793491658"));
+        xmpBasic.setMetadataDate(new java.util.Date(sourcedate));
         if (getUserAgent().getCreationDate() != null) {
             xmpBasic.setCreateDate(getUserAgent().getCreationDate());
         } else {


Obviously hard-coding this is the wrong way to fix this (well, it is
reproducible!), but adjusting it to use SOURCE_DATE_EPOCH like in the
earlier
debian/patches/0001-PDFInfo.java-Support-SOURCE_DATE_EPOCH-environment-v.patch
should hopefully do the trick? I struggle a bit with the Java code
necessary to pull this off myself, but at least identified *where* in
the code it needed to be fixed.

Other packages using fop to generate PDFs seem to mostly be working even
without this:

https://tests.reproducible-builds.org/debian/issues/unstable/timestamps_in_pdf_generated_by_apache_fop_issue.html


live well,
  vagrant