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 easier. 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. --bod -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
