> On Feb 14, 2026, at 4:31 PM, Olivier Dion <[email protected]> wrote:
>
> On Sat, 14 Feb 2026, Ludovic Courtès <[email protected]> wrote:
>> Hello,
>>
>> Simon Josefsson via rb-general <[email protected]>
>> skribis:
>>
>>> HP-UX 'make' treats mtime 0 as a missing file, and POSIX encourage it:
>>>
>>> https://lists.gnu.org/archive/html/bug-gnulib/2024-12/msg00209.html
>>> https://lists.gnu.org/archive/html/bug-gnulib/2024-12/msg00227.html
>>>
>>> If you want to depend on GNU make behaviour, all is good.
>>
>> The Nix build daemon (and thus the Guix daemon) “forever” used mtime = 1
>> to work around software that gives mtime == 0 special treatment:
>>
>> https://github.com/NixOS/nix/commit/14bc3ce3d6d5745717fa19b8b43b5fdd117ff757
>>
>> It’s probably safer to avoid mtime == 0!
>
> I knew it! I knew that some software would somehow think 0 is special
> and break! Thanks for the info!
I personally prefer a "meaningful" datetime stamp, since that provides
additional information. But that's a preference about maximally providing
info; clearly choosing "1" can also provide reproducibility
Can these trade-offs be documented somewhere on the r-b website
with SOURCE_DATE_EPOCH? Basically:
* Many prefer setting SOURCE_DATE_EPOCH, MTIME, and --mtime to a
"meaningful" value like `git show HEAD --format=%ct --no-patch`
as this provides additional information.
* For reproducible builds, all that matters is consistency. We recommend against
using "0" as things breaks some tools (like HP-UX make), and POSIX
encourages treating this value specially [where? how?]
If you want to use a fixed value, "1" is safer.
--- David A. Wheeler
P.S.: Maybe use this too from earlier in the posting:
# help2man reproducibility
SOURCE_DATE_EPOCH=$(shell git show HEAD --format=%ct --no-patch 2>/dev/null ||
echo 0)
# Be friendly to Debian; avoid using EPOCH
MTIME=$(SOURCE_DATE_EPOCH)
TAR_FLAGS=--sort=name --mtime=@$(MTIME) --owner=0 --group=0 --numeric-owner
--mode=go=rX,u+rw,a-s
