Allow to override build date with SOURCE_DATE_EPOCH

[bmwiedemann]

in order to make builds reproducible.
See https://reproducible-builds.org/ for why this is good
and https://reproducible-builds.org/specs/source-date-epoch/
for the definition of this variable.
This date call works with various variants of date.

Also use UTC to be independent of timezone.

[codecov-io]

Codecov Report

❗ No coverage uploaded for pull request base (master@1df34c4). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff            @@
##             master     #31   +/-   ##
========================================
  Coverage          ?   73.3%           
========================================
  Files             ?      15           
  Lines             ?     487           
  Branches          ?       0           
========================================
  Hits              ?     357           
  Misses            ?     103           
  Partials          ?      27

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1df34c4...2e40a6e. Read the comment docs.

[corneliusweig]

Thanks for reporting this and providing a fix too! It makes absolute sense to make the build reproducible. As far as I understand, this is just the first step until the build is fully reproducible. For example, the build environment is also not well controlled.

Can you also make sure to include a a sign-off line in your commit, for example git commit --amend --signoff?

[corneliusweig]

I'm a bit worried about all the alternatives here. Quoting the spec for SOURCE_DATE_EPOCH:

The value MUST be an ASCII representation of an integer with no fractional component, identical to the output format of date +%s.

That seems to be covered by the first alternative.

The second looks as if it is using a reference file to obtain a timestamp. As this is not specified by the spec, why should we do that?

Finally, the last alternative seems to be a fallback in case the other ones failed. Here I would rather fail fast and fail the build instead of pretending that everything went fine. WDYT?

[bmwiedemann]

This is to handle different variants of date - the first is for GNU date as used in every GNU/Linux distribution, the 2nd for FreeBSD date and the 3rd one as fallback (e.g. DOS and Solaris date) that have no way to make the output reproducible.

[bmwiedemann]

If you think, that this program will never be built outside of GNU/Linux, we can simplify the code.

[corneliusweig]

I see. So I think the last variant is obsolete, because on these systems people should simply not set the SOURCE_DATE_EPOCH env var and the build will do as expected.
And for the two remaining alternatives, a comment would be nice, such as

GNU and BSD date require different options for a fixed date

I don't mind if the comment is in code or in the commit message, whatever you prefer.

[corneliusweig]

Thanks again for contributing!