On 5 June 2015 at 21:12, Ximin Luo <infini...@pwned.gg> wrote:
> If we're going to mandate that it ends with Z, might I suggest that we add
> "UTC" or "_UTC" to the variable name? It leaves the option open in the future
> that we might allow TZ offsets.
> Note that the TZ offsets mentioned in ISO8601 and the other RFC standards are
> not "time zones" or "local times" that are subject to DST. They are *fixed
> offsets*, and don't require extra context (such as the TZ database) to parse
> correctly. So it would be less of a PITA than you might think.
Agreed: it is a fixed offset which may be applied with little more
than some multiplications by 60 and the appropriate addition and
subtraction. There are however three possible formats which need to
be handled outside of Z if you want to be thorough (±hh:mm, ±hhmm and
±hh), and given that this proposal as I understand it is to have the
build infrastructure set this variable, then pushing the complexity to
that single place and making the changes to the program which needs to
interpret this variable *as simple as possible* is likely to make
convincing the authors of such programs to add the feature somewhat
As far as the naming, given that only programs are going to be
setting/parsing this variable, it can be as descriptive as required
and should be chosen to reduce the possibility of an identically named
variable for another purpose being accidentally interpreted. I'm
presuming that outside the scope of reproducible builds that the
variable would not be set, in which case programs should fall back to
the default behaviour such as using the current date or the
modification of a file--in which case an unrelated variable of the
same name in the environment could be a problem.
Any of UTC_SOURCE_DATE, SOURCE_DATE_UTC or
REPRODUCABLE_BUILD_SOURCE_DATE_UTC would work for me, but outside of
the concerns mentioned above I don't actually care.
Reproducible-builds mailing list