SDE and Y2038

[Chris Lamb]

Hi Bernhard!

I cannot make the summit this year, so just replying quickly here on the SDE spec things you mention:

> 2.1:
> currently it says
>
>>  If the value is malformed, the build process SHOULD exit with a non-zero error code. 
>
> Such error handling causes overly complex patches for handling 
> exceptional cases that should never happen. And ugly patches are less 
> likely to be accepted by upstreams.
>
> I would like to see it changed to 'MAY' .
> Or we could just declare behaviour as undefined in that case.
> Or we add 'implementations MAY ignore a SOURCE_DATE_EPOCH=foo'

I'd be happy with a "MAY" change (or marking it as undefined behaviour). :)

This would indeed make future patches simpler, and would harmonise with most real-world implementations currently out there as well: many of the examples on /docs/source-date-epoch/ do enter some sort of error-ish state, but are not consistent (as you imply). This is in at least two different ways, I think:

Firstly, the Python examples will happily consume "-1337" as an SDE value, but will raise an exception if SDE is "foo". On the other hand, Python won't permit "-133700000000000000" as it outside time_t, so the handling appears inconsistent to someone without experience in this area. The GNU date example has the same behaviour, although the POSIX compatible one will actually fallback due to the use of "||".

Secondly, I will add that any of these errors/tracebacks might not actually cause the actual "build process" to fail as the spec currently SHOULDs. Perhaps the surrounding script isn't "set -e" (or language equivalent), so something might get printed to stderr but the build continues. As an anecdote, an invalid date in a debian/changelog file (more common than you might think), doesn't cause dpkg to fail (or at least it didn't the last time I saw that in the wild).

> 2.2:
> is -5 valid?

Out of interest, are there any good use-cases for this?

> 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)

> 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?


Best wishes,

-- 
      o
    ⬋   ⬊      Chris Lamb
   o     o     reproducible-builds.org 💠
    ⬊   ⬋
      o