On 10 June 2015 at 01:59, Ximin Luo <infini...@pwned.gg> wrote: > 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).
I disagree that SOURCE_DATE_UTC provides no benefit over SOURCE_DATE: at the very least, a program could choose to use it as an uninterpreted string (similar to the proposed --date option at the start of this bug, but from the environment rather than a flag). SOURCE_DATE with an arbitrary offset not so much. I'm happy to accept SOURCE_DATE, SOURCE_DATE_UTC, SOURCE_DATE_EPOCH or even SOURCE_DATE_EXTRACTED_FROM_DEBIAN_CHANGELOG_WITH_NO_INTERPRETATION however. Pick one. --bod -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
