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

[Brendan O'Dea]

On 5 June 2015 at 04:40, Ximin Luo <infinity0 at pwned.gg> wrote:
> On 04/06/15 19:30, Daniel Kahn Gillmor wrote:
>> What TZ should SOURCEDATE have?  ISO8601 is capable of supplying a TZ as
>> well, so the current time could be written in a wide variety of ways
>> while meaning the same instant:
>>
>> 0 dkg at alice:~$ date '+%FT%T%z' && date -u '+%FT%T%z'
>> 2015-06-04T13:25:25-0400
>> 2015-06-04T17:25:25+0000
>> 0 dkg at alice:~$
>>
>> I feel like we should we always set it to UTC, so that the inbound
>> parsed offset would be +0000.  sound sensible?
>>
>
> I had thought about this a bit, and not yet decided the best way - hence why I haven't yet written this idea up on the Debian Wiki. FWIW, here are my thoughts:
>
> - Always setting it to UTC would be "simplest", but then our format wouldn't be ISO8601 - we'd have to say "ISO8601 but omit the offset / ignore any offset". RFC 2822 and 3339, the other formats mentioned in `man date`, also include an offset.

Given that you're basically creating a standard here, you get to
mandate the format.

I would say that it must be in ISO 8601 format, in the UTC timezone,
preferably using the "Z" suffix, and if the program interprets that
date and emits it in some way then it should be also in UTC.

  2015-06-05T01:08:20Z
  2015-06-05T01:08:20+0000

> - It's neater to keep the TZ-offset the same as in debian/changelog. Generated dates will then be consistent with debian/changelog. If debian/changelog says "Mar 2015", then the generated documentation will say "Mar 2015".

Local times, and daylight savings are just too much of a PITA.  Just
use UTC and if builds on the first of the month are possibly different
to the changelog, so be it.

> - However, it seems awkward to get date(1) to preserve the original offset. I suppose this is an artefact of using localtime(3) as you mentioned. In general the libc time stuff seems to have disastrous behaviour if you want to play with time zones other than local time or UTC, and this affects some other languages like python.
>
> - One can maybe hack around it with the TZ envvar, but it has a very weird syntax [1], and the hack is dependent on the actual value:

The TZ syntax dates back to when all systems were in the Northern
Hemisphere, and pretty much all folks cared about was EST5EDT
(Eastern) and PST8PDT (Pacific).

> $ date -d "2015-06-04T20:18:13+0800" --iso-8601=seconds
> 2015-06-04T14:18:13+0200 # nope, my local TZ is different
>
> $ TZ="UTC+08" date -d "2015-06-04T20:18:13+0800" --iso-8601=seconds
> 2015-06-04T04:18:13-0800
>
> $ TZ="UTC-08" date -d "2015-06-04T20:18:13+0800" --iso-8601=seconds
> 2015-06-04T20:18:13+0800 # argh, TZ expects the opposite sign
>
> [1] http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html
>
> - A possible workaround is to advise people to just extract the information directly out of SOURCEDATE using a regex (or strip off the last 5 chars of SOURCEDATE before giving it to localtime, maybe). But such advice is extra mental work for developers who may not bother reading the document that we put such advice on.

Mandate input/output in UTC and give a few examples.

  export SOURCEDATE=2015-06-05T01:08:20Z

  Shell:
    $ date -u -d $SOURCEDATE;
    Fri Jun  5 01:08:20 UTC 2015

  Perl:

    use Time::Local 'timegm';
    my $sourcedate = $ENV{SOURCEDATE};
    my ($year, $mon, $mday, $hour, $min, $sec) =
        $sourcedate =~
/^(\d{4})-(\d\d)-(\d\d)T(\d\d):(\d\d):(\d\d)(?:Z|\+0000)$/;
    my $d = timegm $sec, $min, $hour, $mday, $mon-1, $year;
    print scalar gmtime $d;

  Python:

    etc.

>>> It would be awesome for help2man to support this.
>>
>> help2man (and any other tool that accepts $SOURCEDATE) would also need
>> to ensure that it extracts the parts it wants in a TZ-independent
>> fashion as well.  (not parsing back to localtime)

I'm happy to add this.

--bod