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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds