SDE and Y2038

Bernhard M. Wiedemann bernhardout at lsmod.de
Tue Sep 22 06:00:04 UTC 2026



On 21/09/2026 22.07, Chris Lamb wrote:

>> 2.2:
>> is -5 valid?
> 
> Out of interest, are there any good use-cases for this?

No use-case. I'd prefer to have the spec limit valid values to 
*positive* or *non-negative* integers.
I was just worried that some functions might return -1 on error that 
could wrap around in uint64_t types (which don't make sense to use)

>> 2.3:
>> A related question:
>> Is 0 a valid timestamp for SDE?
> 
> I think 0 should be a valid timestamp; after all, the UNIX epoch is a rather famous timestamp (!) and therefore a very useful value to encode in some situations as it is recognisable. A number of projects seem to believe it 0 is valid, too. for instance, here is openssl explicitly making it valid:
> 
>    https://github.com/openssl/openssl/issues/25475
> 
> ... although this simply underscores the issues with undef/false that you raise. ("||" vs "//" in Perl)

perl is the easy case.
In C, atoll returns 0 on parse errors, so an explicit SDE=0 would go 
through the error-path of a minimalist implementation with atoll and be 
counted the same as undef.

I agree, that the epoch value is iconic, but would propose to use SDE=1 
instead for 1970-01-01T00:00:01 .

>> 2.4:
>> Is it OK to use as a flag to mean "want reproducible output" ?
>> I have been doing that in several places, because it is the only
>> reliable indication we have atm.
> 
> I am also using it for this purpose with the exact same logic: if we see a value for SDE, you probably want a reproducible build even in areas outside of timestamps, right? I'm often doing something like this in a "transitive" situation -- for instance, patching a build tool so that when that tool is used to build *another* package some other time, it won't use nondeterminstic values.
> 
> If you recall though, TeX disliked this (arguably maximalist) approach, requiring maintainers to specify FORCE_SOURCE_DATE to indicate that they really do want the \date macro to be deterministic.
> 
> Do you think this warrants something in the spec or just something in the docs?

It caused some discussion in a few of my PRs, because I link to the 
spec. Adding a short note about it, could help there.


In general, there are two parts to SDE. A sender and a receiver and we 
should apply different standards to them.
E.g. a sender SHOULD set values between 1 and 10000000000 and MUST stay 
below LLONG_MAX.
While a receiver MUST handle this range as good as possible, it MAY also 
accept values between LLONG_MIN and LLONG_MAX (but we don't even need to 
specify that)


Ciao
Bernhard M.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20260922/dfc58efc/attachment.sig>


More information about the rb-general mailing list