Re: [nmh-workers] Reproducible build patch

[Robert Elz]

    Date:        Fri, 27 Jul 2018 12:57:36 +0100
    From:        Ralph Corderoy <address@hidden>
    Message-ID:  <address@hidden>

  | but despite the man page, it's not obvious to me that the `epochdate'
  | rule indicates the gmtime_r(3) error.

I know now what the NetBSD parsedate(3) man page (which might have
been my words, I forget...) was trying to say (and doing it very badly, I will
fix that, or at least hopefully improve it) ...

parsedate() input has 2 parts, a specification of a base (starting) time, and
an offset from that time.   Both are optional (a null string just means 
midnight today).

The @nnnn (seconds since epoch) form, is specifying the base time, and the
text:

     Seconds since epoch, UTC, (also known as UNIX time) are also supported:
     @735275209  Tue Apr 20 03:06:49 UTC 1993
     provided that the value given is within the range that can be represented
     as a struct tm.  Negative values (times before the epoch) are permitted,
     but no other significant data.

(or the "no other significant data" part, which is the issue) is intending to
indicate that stuff like ...

        date -u -d "@$(date +%s) 15:00"

is not supported, and it isn't, that gets rejected.    But the "significant" 
gives room for some weirdness...

        date -u -d "@$(date +%s) Weds"

is accepted, the meaningless (and incorrect - it is Saturday) "Weds" is
simply ignored (that's insignificant - when included along with anything
that specifies a date, any weekday name given is generally just ignored.)

However, the other part of the parsedata input can, if desired, be applied
along with (any form of, including an epoch_date) spec of the base time,
so

        date -u -d "@$(date +%s) +2 months"
        Fri Sep 28 14:23:45 UTC 2018

That is intended.

I will see about improving parsedate's man page to make that clearer.

Thanks for pointing it out.

kre