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),
http://cvsweb.netbsd.org/bsdweb.cgi/src/bin/date/date.c?rev=1.61&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
http://netbsd.gw.com/cgi-bin/man-cgi?parsedate++NetBSD-current
but despite the man page, it's not obvious to me that the `epochdate'
rule indicates the gmtime_r(3) error.
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libutil/parsedate.y?rev=1.32&content-type=text/x-cvsweb-markup
GNU date also accepts text that doesn't match the Reproducible-Builds
spec.
$ 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.
https://reproducible-builds.org/specs/source-date-epoch/#idm53
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.
https://plus.google.com/+RalphCorderoy
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers