I've had a look at the other commands we've identified which accept date strings:

at(1)/batch(1) has a very similar (but not identical) implementation of date string parsing, with the same flaws as date(1).

calendar(1) differs more, it doesn't validate for impossible months or days either.

cal(1) is rather distinct from any of the other commands I looked at. It appears very thorough on a glance through the code, and it correctly detects impossible months and years.

pax(1), basically the same code as at(1), same flaws.

touch(1), same code as at(1), same flaws.

ca(1) from OpenSSL seems to have pretty reasonable verification, but there are oversights: it doesn't validate days of month, and it doesn't take into account UTC leap seconds, though I'm possibly being overly pedantic in pointing the latter out.

fsdb(8) doesn't really have any validation, other than ensuring only digits were supplied and that mktime() likes what it receives (which as we know from date(1) isn't a thorough arbiter of correct understanding of human intention).

newsyslog(8) has two different applicable functions apparently written at different times, parse_dwm() looks good though it could have used isleap() from tzfile.h instead of rewriting it, also it has the value 1900 hard-coded instead of using TM_YEAR_BASE.  (I think I noticed that somewhere else too.)  It also has a redundant if statement at the bottom of the validation code (why check for > 31 and > nday?).  parse_iso8601() has validation code with an off-by-one error for the month (should be > 11 not > 12), does not validate day of month, and misses one leap second.

Dave
> 
> From: David H. Gutteridge <dhgutteridge@sympatico.ca>
> Date: 2004/11/29 Mon PM 11:31:00 EST
> To: Martin Husemann <martin@duskware.de>
> CC: <gnats-admin@netbsd.org>, <netbsd-bugs@netbsd.org>
> Subject: Re: Re: bin/28450: date(1) does not validate its input and accepts and processes
> 
> Sure, I'll add something to that effect when I get a moment and I'll have a look around at other commands.  So far I've noted the following commands accept dates in basically the same format:
> 
> at(1) and its aliases
> cal(1), much simpler though
> pax(1)
> touch(1)
> ca(1), errr, part of OpenSSL
> fsdb(8)
> newsyslog(8)
> 
> A separate matter would be the question of what validation is done on dates supplied for the user database.  (I see what you mean about arms, heh.)
> 
> Dave
> > 
> > From: Martin Husemann <martin@duskware.de>
> > Date: 2004/11/29 Mon AM 03:35:40 EST
> > To: dhgutteridge@sympatico.ca
> > CC: gnats-admin@netbsd.org,  netbsd-bugs@netbsd.org
> > Subject: Re: bin/28450: date(1) does not validate its input and accepts and processes impossible dates
> > 
> > On Mon, Nov 29, 2004 at 03:45:00AM +0000, dhgutteridge@sympatico.ca wrote:
> > > I have supplied a proposed patch which
> > 
> > You know, if you reach a finger we'll take your arm...
> > 
> > I like this, but I think it might make sense to have badvalue() print the
> > "decoded" date string, as the format is .. not exactly human friendly,
> > given how many variations of the order exists and the many optional parts...
> > 
> > While there, could you check other commands that take a date string?
> > at(1), cal(1), probably others.
> > 
> > Martin
> > 
>