Debian and SOURCE_DATE_EPOCH=0

[Vagrant Cascadian]

On 2026-02-20, David A. Wheeler via rb-general wrote:
>> On Feb 20, 2026, at 12:37 PM, Vagrant Cascadian <vagrant at reproducible-builds.org> wrote:
>> 
>> In my opinion, SOURCE_DATE_EPOCH should really be a timestamp of last
>> resort, the preferred thing is to not include build timestamps at all!
>
> It's easier to reproduce data if there are no timestamps embedded in it, sure.
>
> However, receivers generally don't perceive these timestamps as "build" timestamps.
> They aren't marked that way. They are simply "timestamps", and are required parts
> of many formats (zip and tar for example). The real goal is to make them reproducible.
> That can be done with:
>
> * Meaningless reproducible value (like "1")
> * Meaningful reproducible value (e.g., datetime of last git commit in source)

I strongly believe no timestamp is better than a meaningless value. That
is not always an option (e.g. zip and tar, as you pointed out). If a
timestamp can be dropped entirely, and in many cases it can be, it is
certainly better than an effectively meaningless timestamp.


> I personally think that providing end-users with meaningful data, when we can,
> is helpful. Users often don't get enough meaningful data!

In many cases even with SOURCE_DATE_EPOCH set to a meaningful timestamp
it can even be more misleading that no timestamp at all (or a seemingly
meaningless/absurd one (e.g. 0, 1, 315561600))...

As one example, many projects wrongly include auto-generated copyright
lines with the "current" year, and even manage to respect
SOURCE_DATE_EPOCH, but still produce incorrect copyright lines by using
the last modified source time, even though the content described was
unmodified for years or decades.

There are probably other similarly misleading uses of meaningfully
reproducible timestamps... bringing me to the point of questioning
"meaningful".

This is why SOURCE_DATE_EPOCH should be seen as a grudging hack that is
necessary in some cases (e.g. zip, tar), and reluctantly needed to avoid
having to patch out all the timestamp problems in all the world's source
code, but ... it is at best a workaround more than a correct solution,
for an imperfect world.


> But this is a personal preference that different people can conclude differently
> (even the same person for different circumstances!). It's yet another trade-off.

Agreed.


> What matters, in the end, is reproducibility so we can eliminate
> a variety of attacks.

Sure, that goes without saying, or, well, I guess sometimes it needs
saying... :)


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20260220/13bac315/attachment.sig>