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 

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 

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 


 or http://lists.denx.de/pipermail/u-boot/2015-July/221301.html


Attachment: signature.asc
Description: OpenPGP digital signature

Reproducible-builds mailing list

Reply via email to