Make mdz create output deterministic (honor SOURCE_DATE_EPOCH)
Problem
mdz create stamps the wall clock into the archive, so re-running it on unchanged sources produces a byte-different .mdz every time:
- manifest
created/modified timestamps (new Date().toISOString())
- zip entry modification dates (DOS date/time from
new Date(), which also depends on the local timezone)
For consumers that commit generated .mdz (e.g. mdzip.org commits assets/docs/*.mdz, built via the CLI in build:mdz), every build dirties the tree with byte-only diffs even when nothing changed.
Request
Support reproducible builds by pinning the clock when requested:
- Honor the
SOURCE_DATE_EPOCH environment variable (seconds since epoch — the de-facto reproducible-builds standard) for both the manifest timestamps and the zip entry dates.
- Optionally a
--source-date/--mtime flag as an explicit equivalent.
- Use UTC for the zip DOS date derivation so output doesn't vary by timezone.
When set, two runs over identical inputs should produce byte-identical archives.
Reference
@mdzip/core-js's MdzPackagerCore.buildArchive has the same wall-clock behavior and no override. mdzip.org worked around it for its in-process sample builds by pinning globalThis.Date + TZ=UTC in scripts/build-samples.mjs, but that trick can't reach the CLI (it's a separate process), so build:mdz archives remain non-deterministic. A SOURCE_DATE_EPOCH-aware CLI (ideally backed by a timestamp option in core-js's packager) is the proper fix.
Make
mdz createoutput deterministic (honorSOURCE_DATE_EPOCH)Problem
mdz createstamps the wall clock into the archive, so re-running it on unchanged sources produces a byte-different.mdzevery time:created/modifiedtimestamps (new Date().toISOString())new Date(), which also depends on the local timezone)For consumers that commit generated
.mdz(e.g. mdzip.org commitsassets/docs/*.mdz, built via the CLI inbuild:mdz), every build dirties the tree with byte-only diffs even when nothing changed.Request
Support reproducible builds by pinning the clock when requested:
SOURCE_DATE_EPOCHenvironment variable (seconds since epoch — the de-facto reproducible-builds standard) for both the manifest timestamps and the zip entry dates.--source-date/--mtimeflag as an explicit equivalent.When set, two runs over identical inputs should produce byte-identical archives.
Reference
@mdzip/core-js'sMdzPackagerCore.buildArchivehas the same wall-clock behavior and no override. mdzip.org worked around it for its in-process sample builds by pinningglobalThis.Date+TZ=UTCinscripts/build-samples.mjs, but that trick can't reach the CLI (it's a separate process), sobuild:mdzarchives remain non-deterministic. ASOURCE_DATE_EPOCH-aware CLI (ideally backed by a timestamp option in core-js's packager) is the proper fix.