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