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

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 

- In Java, one does "new Date(timestamp) and then uses DateFormat with an 
explicit scope-restricted TimeZone (none of this tzset global variable 
- 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 
  - 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 

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" 


[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


Attachment: signature.asc
Description: OpenPGP digital signature

Reproducible-builds mailing list

Reply via email to