Inconsistent ${maven.build.timestamp} values caused by JVM time zone differences

Short answer

A dedicated maven.build.timestamp.timezone property is a reasonable, narrowly scoped fix for the symptom described, but it should not be presented as a reproducibility feature. If the goal is byte-identical artifacts, the stronger lever is project.build.outputTimestamp combined with removing wall-clock timestamps from generated content. Treat the property proposal as version-sensitive: verify it against the exact Maven version your build uses before depending on it.

Why the values differ

Confirmed enough to act on for Maven 3.x: ${maven.build.timestamp} is rendered through SimpleDateFormat using the JVM default time zone (user.timezone). Two agents in different zones therefore format the same instant into different strings. The value is local wall-clock time; it is not inherently UTC.

Likely explanation for the reported inconsistency: the timestamp is interpolated into a generated source, manifest, or resource, and each agent's default zone shifts the rendered offset. That is a rendering difference, not a different build instant.

Caution worth flagging for review: the default format often ends in a literal Z. In many Maven 3.x configurations that is a quoted literal, not a UTC designator, so do not read Z as proof of UTC.

How it would interact with the format setting

Cleanly, and that is the appeal. The two settings are orthogonal:

• maven.build.timestamp.format selects the pattern — which fields appear, their order, and quoting.
• A timezone setting would select the zone or offset used when those fields are rendered.

Neither changes the underlying instant. If the pattern contains a zone or offset field, it renders the selected zone; a quoted literal stays literal. The property would therefore make the string deterministic across agents without touching the JVM default, which is exactly the constraint in the question.

What it would not fix

• Plugins that call new Date() or their own SimpleDateFormat with the default zone would still vary. A Maven-only property does not reach them.
• Archive entry timestamps, file ordering, and dependency resolution remain non-deterministic inputs. project.build.outputTimestamp is the mechanism aimed at normalizing artifact entry timestamps.
• Global -Duser.timezone=UTC does fix the timestamp, but it is broader: logging, plugin behavior, and file or archive metadata can all shift.

Verification you can run

mvn -version
mvn help:evaluate -Dexpression=maven.build.timestamp -DforceStdout
TZ=America/Los_Angeles mvn help:evaluate -Dexpression=maven.build.timestamp -DforceStdout
TZ=Asia/Tokyo mvn help:evaluate -Dexpression=maven.build.timestamp -DforceStdout

Compare the three outputs. Then confirm whether a maven.build.timestamp.timezone property is recognized by your version — if it is not, it is silently ignored, so test rather than assume. Finally, build the same commit in two zones and compare artifact hashes, then set a fixed project.build.outputTimestamp and repeat the comparison.

One detail that changes the recommendation

Where does the timestamp end up? If it lands in a generated source, manifest, or resource that is hashed into the artifact, a timezone property only makes the string consistent — it does not make the artifact reproducible unless the value is also fixed. If it is used only for display or logging, the property alone is sufficient. Inspect the effective POM and each plugin that consumes timestamps before choosing.

Items to review with your team: whether Maven 4 changes timestamp handling or reproducibility defaults, and whether the Maven project has settled on a dedicated property. This brief cannot confirm either; pin your Maven version and test.