[U-Boot] [RFC PATCH] Makefile: Add SOURCE_DATE_TZ

[Ximin Luo <infinity0@pwned.gg>]

On 01/08/15 20:47, Paul Kocialkowski wrote:
> Le samedi 01 ao?t 2015 ? 22:32 +1200, Chris Packham a ?crit :
>> Along with SOURCE_DATE_EPOCH SOURCE_DATE_TZ can be used to recreate a
>> build with a specific date timestamp. This allows the verification of
>> source supplied with a pre-compiled binary.
>>
>> If SOURCE_DATE_EPOCH is supplied SOURCE_DATE_TZ can be used to specify
>> what will appear in the output of the version command. If SOURCE_DATE_TZ
>> is not specified UTC will be used.  SOURCE_DATE_TZ on it's own will not
>> have an affect.
> 
> Well, I worked with the assumption that SOURCE_DATE_EPOCH would always
> be provided in UTC, but I see no harm in providing SOURCE_DATE_TZ as
> well, provided that it falls back to UTC when not set, as is the current
> behaviour of tour patch.
> 

To clarify, SOURCE_DATE_EPOCH is a unix timestamp which is defined as the number of seconds (excluding leap seconds) since Jan 1 1970 UTC. There is no way to specify this "in another timezone"; there is no ambiguity here.

However, I am not sure that us at Reproducible Builds will actually adopt this variable. We haven't talked about it beyond my previous email [1], it was just me quickly skimming off my thoughts and firing off quick ideas. My personal concern about SOURCE_DATE_TZ is that it implies that it could take actual named time zones, like "EST" or "Europe/London"; it is **extremely unlikely** that we will do anything like this soon, because this would involve timezone databases and complex things like that. This is why in my previous email I suggested the SOURCE_DATE_TZOFFSET variable. Also, the TZ variable as specified by POSIX specifies the offset in the *opposite* direction to what ISO8601 and RFC2822 displays.

The git internal timestamp format only supports timezone offsets in the common direction, opposite to TZ, i.e. positive for east of Greenwich and negative for west.

I'd suggest to leave out SOURCE_DATE_TZ for now, until we come up with a more precisely defined *meaning* for this variable. It is meant to be a standard across all tools, so some time to think through the issues is necessary. Otherwise we risk leaving a clusterfuck of a legacy, like the POSIX time functions.

X

[1] https://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20150727/002562.html or http://lists.denx.de/pipermail/u-boot/2015-July/221301.html

-- 
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/20150802/4bc9a798/attachment.sig>