Inconsistent timezone offset in PDF CreationDate across pdfTeX, XeTeX and LuaTeX

Answer

No. The LaTeX kernel does not provide timezone-aware primitives and there is no kernel-supported way to normalize PDF /CreationDate and /ModDate to a common reference such as UTC without external tooling or manual assignment. As of the 2024-2025 releases the LaTeX3 project has no implemented timezone-aware date primitives; the design question of a kernel layer versus package responsibility remains unresolved with no consensus.

Confirmed facts

• The LaTeX kernel provides no timezone-aware primitives. \today and \time reflect the TeX engine internal clock derived from system local time without zone information.
• datetime2's \DTMnow formats the current date and time but does not apply timezone conversion; it prints the timestamp supplied by the operating system.
• pdfTeX exposes \pdfcreationdate and \pdfmoddate primitives that can be set manually. The engine-generated default /CreationDate and /ModDate use local system time and are written in PDF D:YYYYMMDDHHmmSS±HH'mm' form with a timezone offset derived from the OS timezone at run time.
• There is no kernel-supported primitive to normalize timestamps to a common reference without external tooling or manual assignment. Normalization requires user-supplied \pdfcreationdate/\pdfmoddate values or post-processing.
• As of the 2024-2025 releases, the LaTeX3 project has no implemented timezone-aware date primitives. The design question remains unresolved with no consensus.

Likely engine-specific behavior

Engine and driver versions change date handling and behavior is version-sensitive and OS-dependent.

• XeTeX delegates PDF output to xdvipdfmx. Driver-generated /CreationDate and /ModDate are based on local time and offset handling is driver-version dependent, commonly observed as local offset or UTC-style notation in practice, leading to inconsistent offsets across distributions and versions.
• LuaTeX's own PDF writer sets /CreationDate and /ModDate from the engine clock using local time with an offset that can be overridden via \pdfcreationdate/\pdfinfo. Default behavior is version-sensitive and not normalized to UTC, so reproducibility varies with engine release and system timezone.

Steps needed for this case

1. Verify current metadata. Compile a minimal document with each engine and inspect metadata with a PDF tool such as pdfinfo or qpdf --show-metadata to read the raw /CreationDate string and note offset presence and sign.
2. Record versions. Check engine and driver versions via pdftex --version, xetex --version and xdvipdfmx --version, and LuaTeX version, then repeat the compile under a controlled TZ to observe offset changes.
3. Control reproducibility if required. Set TZ to a fixed zone before compilation and compare outputs across engines, or manually set a normalized date with \pdfcreationdate{D:YYYYMMDDHHmmSSZ} or \pdfcreationdate{D:YYYYMMDDHHmmSS+00'00'} to force a common reference. Note that manual assignment must follow PDF date syntax exactly to avoid invalid metadata.

System TZ environment affects the local time used by all three engines, so identical source can yield different offsets on different machines.

One diagnostic detail that changes the recommendation: which xdvipdfmx version is used with your XeTeX installation. XeTeX offset behavior depends on xdvipdfmx version, not only on XeTeX itself.