SOURCE_DATE_EPOCH=0 (1970-01-01) rejected by timestamp range validation since 3.4.2

[gnodet]

Problem

maven-jar-plugin 3.4.2 (via maven-archiver) enforces a valid timestamp range of 1980-01-01T00:00:02Z to 2099-12-31T23:59:59Z on project.build.outputTimestamp. When SOURCE_DATE_EPOCH=0 (Unix epoch, 1970) is set — a common reproducible-build convention used by Debian and many Apache projects — the build fails with:

Error assembling JAR: '1970-01-01T00:00:00Z' is not within the valid range 1980-01-01T00:00:02Z to 2099-12-31T23:59:59Z

This was working fine with maven-jar-plugin 3.3.1. The range constraint comes from the ZIP/JAR format requiring timestamps ≥ 1980, which is correct for the JAR's internal entry timestamps — but the user-visible error message is confusing and there is no automatic clamping to DATE_MIN.

Steps to reproduce

1. Set SOURCE_DATE_EPOCH=0 (or project.build.outputTimestamp=1970-01-01T00:00:00Z) in your build environment.
2. Build a project using maven-jar-plugin 3.4.2.
3. Build fails with the above error.

Expected behavior

Either:

• Clamp automatically: If project.build.outputTimestamp is before DATE_MIN (1980-01-01T00:00:02Z), use DATE_MIN instead and emit a warning. This is what many other tools do.
• Or reject with a clear message: Document the minimum accepted value and link to the reproducible-builds guidance that SOURCE_DATE_EPOCH must be ≥ 315532802 (1980-01-01T00:00:02Z) when used with JDK jar tooling.

Affected versions

• 3.4.2 (regression vs 3.3.1)

Context

Found while running Maven 4 compatibility tests across Apache projects. Affected projects: sling-org-apache-sling-karaf-integration-tests, sling-org-apache-sling-karaf-launchpad-oak-tar-integration-tests.

The Reproducible Builds mailing list documents that SOURCE_DATE_EPOCH=0 is commonly used and that the JDK jar tool imposes the 1980 floor — a clear error message or automatic clamping would help users.