[Reproducible-builds] Bug#787444: Bug#787444: help2man: support externally-supplied --date for reproducibility

[Ximin Luo]

On 06/06/15 16:39, Holger Levsen wrote:
> Hi,
> 
> 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[1], which unfortunately influences a lot of other naive language libraries such as Python[2], PHP[3], Perl[4], 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"))
1433854212.0

contrast with:

>>> import time
>>> time.gmtime(1433854212)
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[5] 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).
- In Javascript, one also does "new Date(timestamp)" then call getUTC{Hours,Seconds} etc on the resulting object.

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).

X

[1] http://pubs.opengroup.org/onlinepubs/007908799/xsh/time.h.html
[2] https://docs.python.org/2/library/time.html
[3] https://php.net/manual/en/ref.datetime.php
[4] http://perldoc.perl.org/index-functions-by-cat.html#Time-related-functions
[5] https://php.net/manual/en/function.gmmktime.php

-- 
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.alioth.debian.org/pipermail/reproducible-builds/attachments/20150609/6752ee0a/attachment.sig>