[U-Boot] [Reproducible-builds] [U-Boot, v2] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH

[Ximin Luo <infinity0@pwned.gg>]

On 31/07/15 07:25, Chris Packham wrote:
> The problem is that date -u implies UTC. So +0000 is right if you do
> want the time to be displayed in UTC (for me living at +12/+13 UTC
> makes my head hurt because all the dates are yesterday).
> 

One of the main problems with human-readable date/time is that it implies a calendar, with all its exceptions like leap years, changing DST, etc. Many RFCs, and the POSIX date functions, are highly flawed and conflate calendars with absolute time, e.g. don't specify they mean the Gregorian calendar, and don't specify what to do with dates before when the Gregorian calendar was introduced.

If you want to be precise about these things (so as to not cause problems in the future), then you need to specify all of that when dealing with human-readable dates. This is why for now, the Reproducible Builds timestamps proposal only defines SOURCE_DATE_EPOCH. We might extend it later, though.

> The intent of f3f431a7 was to reflect the timezone that the build
> machine was set to. Dropping the -u would probably be sufficient but
> perhaps it would be better to make whole lot conditional on
> SOURCE_DATE_EPOCH being set. Something like this (untested, apologies
> gmail web interface)
> 
> ifneq ($(SOURCE_DATE_EPOCH),)
> define filechk_timestamp.h
>        (SOURCE_DATE="$(SOURCE_DATE_EPOCH)"; \
>        LC_ALL=C date -u -d "$${SOURCE_DATE}" +'#define U_BOOT_DATE "%b
> %d %C%y"'; \
>        LC_ALL=C date -u -d "$${SOURCE_DATE}" +'#define U_BOOT_TIME "%T"'; \
>        LC_ALL=C date -u -d "$${SOURCE_DATE}" +'#define U_BOOT_TZ "%z"' )
> endef
> else
> define filechk_timestamp.h
>        (LC_ALL=C date +'#define U_BOOT_DATE "%b %d %C%y"'; \
>        LC_ALL=C date +'#define U_BOOT_TIME "%T"'; \
>        LC_ALL=C date +'#define U_BOOT_TZ "%z"')
> endef
> endif
> 

Yes, it is best to force the TZ as UTC for now, if SOURCE_DATE_EPOCH is set.

At some point later, we might add SOURCE_DATE_TZOFFSET, or other formats that include a timezone offset, or something. (That would match Git's internal timestamp format, which is "$epochts $tzoffset", and can be translated unambiguously into ISO8601 and RFC2822 formats). For now though, we decided to keep things simple. But please say so, if you think that is something you (or others who use timestamps in build systems) would really want.

BTW, you need to do "@$${SOURCE_DATE_EPOCH}" when giving timestamps to date(1):

$ date -d @1438330000 +%s
1438330000
$ date -d 1438330000 +%s
date: invalid date ?1438330000?
1

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150731/79985a4a/attachment.sig>