Hi kre,

> As I said, I know (somewhat) the -d parser on netbsd, which I know
> handles the @N form, but I kind of doubt has much in the way of error
> checking there.

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

GNU date also accepts text that doesn't match the Reproducible-Builds

    $ date -ud '@  003.1415'
    1970-01-01 00:00:03 +0000 Thu

> If you really believe in that, then you need to do the validation.

Here's the specification again.
It doesn't sufficiently spell out what's valid.

     The value MUST be an ASCII representation of an integer with no
     fractional component, identical to the output format of date +%s.

So that means it matches /^(0|-?[1-9][0-9]*)$/ in the interval
[-67768040609740800, 67768036191676800) given a 64-bit signed time_t
with a 32-bit signed year.  (Though POSIX doesn't state time_t need be
bigger than 32 bits, or if it's signed.)

    It SHOULD be set to the last modification time of the source,
    incorporating any packaging-specific modifications. 

That would bring it back into reasonable bounds, but it's only a SHOULD.

I'm thinking if it matches the above regexp, and gmtime(3) is happy,
then that's good enough.

Cheers, Ralph.


Reply via email to