[Reproducible-builds] Bug#787444: Bug#787444: help2man: support externally-supplied --date for reproducibility
infinity0 at pwned.gg
Tue Jun 9 15:59:52 UTC 2015
On 06/06/15 16:39, Holger Levsen wrote:
> On Freitag, 5. Juni 2015, Daniel Kahn Gillmor wrote:
>> My vote is for SOURCE_DATE_UTC, and i agree with Brendan that we should
>> take the opportunity to define this as strictly and narrowly as possible
>> (i.e. end in a 'Z', none of the other offsets), so that people relying
>> on it know they're getting a fixed thing, and don't have to implement
>> any fancy parsing/offsetting code if they're not already using an
>> ISO8601-compliant date-parsing library.
> sounds good to me too!
Sorry to go back on this a little bit.
Going through the POSIX time functions, which unfortunately influences a lot of other naive language libraries such as Python, PHP, Perl, I suggest that we define SOURCE_DATE_EPOCH (name open to discussion) instead:
SOURCE_DATE_EPOCH = "$(date -d "$(dpkg-parsechangelog --count 1 -SDate)" +%s)" # unix timestamp
The reason is that most languages have the "gmtime()" POSIX function to convert a unix timestamp into a time-tuple. However, not every language has an easy way to convert from SOURCE_DATE_UTC into the other options - because the POSIX time functions don't. Often, one needs to do, e.g.:
>>> import os, time
>>> os.environ["TZ"]="UTC"; time.tzset(); time.mktime(time.strptime("2015-06-09T12:50:12Z", "%Y-%m-%dT%H:%M:%SZ"))
>>> import time
time.struct_time(tm_year=2015, tm_mon=6, tm_mday=9, tm_hour=12, tm_min=50, tm_sec=12, tm_wday=1, tm_yday=160, tm_isdst=0)
Granted, PHP has gmmktime but this is non-standard.
More examples of other languages, where it's more "basic" to work with unix timestamps:
- In Java, one does "new Date(timestamp) and then uses DateFormat with an explicit scope-restricted TimeZone (none of this tzset global variable business).
Given the above, I think it would still be good to define SOURCE_DATE as I originally suggested:
SOURCE_DATE = "$(date -d "$(dpkg-parsechangelog --count 1 -SDate)" --iso-8601=seconds)" # includes the TZ offset
- if the language/tool already has/uses a ISO8601 parser in its standard library, this is as convenient as the previous SOURCE_DATE_UTC
- if the language/tool doesn't have/use one, then SOURCE_DATE_UTC doesn't actually give us any benefits:
- it's far easier to use SOURCE_DATE_EPOCH, if you want to play with the date programmatically
- OTOH if you're just going to take substrings/regex-match it, this works just as easily for SOURCE_DATE vs SOURCE_DATE_UTC, and the former contains more information
But I care less about this latter point; the main point of this email is to argue for SOURCE_DATE_EPOCH over SOURCE_DATE_UTC (iso8601 locked to "Z" timezone).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the Reproducible-builds