Date: Tue, 24 Jul 2018 13:16:21 +0100 From: Ralph Corderoy <ra...@inputplus.co.uk> Message-ID: <20180724121621.ee43a21...@orac.inputplus.co.uk>
| So I think `:-' is the wrong test, and `:' should be used. I saw the correction in the subsequent msg, and the correct usage in your example -- but really? Is failing (well, planning to fail, and faliing at that) when the SOURCE_DATE_EPOCH is set to a null string, rather than treating that as the same as not set at all really that important? | How about | | fmt='%Y-%m-%d %T %z' Since this always uses date -u (correctly I think) the %z is overkill, just use fmt='%Y-%m-%d %TZ' instead. And maybe make it more isoish by using T instead of the space. Then for the failing to fail... | now="${SOURCE_DATE_EPOCH-$(date +%s)}" That will leave now a null string, as you intended, if SOURCE_DATE_EPOCH is set to "" - and a null string is invalid as an arg to both -d@ and -r so ... | date="$( | exec 2>/dev/null | date -u -d "@$now" +"$fmt" || | date -u -r "$now" +"$fmt" || | date -u +"$fmt" | )" With null "$now" that ends up doing the 'date -u +"$fmt"' (which is definitely not a reproducible build, but I guess that is the point) but is most certainly not obeying the: The value MUST be an ... (otherwise) the build process SHOULD exit with a non-zero error code. If that is to be ignored anyway (which I think is reasonable - anyone who wants a correct reproducible build should give the correct value) then I see no particularly good reason to not treat a set but null SOURCE_DATE_EPOCH the same as an unset one. Ie: leave the ':' in... You'd get the same result with less failed date invocations if you just allow "now" to be set to, well, now, when SOURCE_DATE_EPOCH is null. kre ps: the "" around the date=$( ) are not really needed - they do no harm but provide no benefit either. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers