-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Sep 02, 2002 at 10:54:24PM -0700, Russ Allbery wrote:
> So today, in-between writing with friends, I played about with something
> that I've been wanting to play with since I first saw parsedate, namely a
> hand-written RFC 2822 date parser.

[...]

> There are a bunch of other random, scattered problems, but far and away
> the most common is the lack of a leading digit on the hour.  Which is
> rather interesting.  I'm guessing that this must be a flaw in a particular
> piece of software.

Maybe you can use the message-id's to retrieve the articles and try to
figure out where these messages originated?

[...]

> Whether to use the parser in INN is another question.  Examining the INN
> source base, the only program that uses parsedate to do anything other
> than parse date headers in articles is convdate, and as useful as convdate
> sometimes can be, one can whip up something very similar with Perl and
> Date::Manip that can recognize a lot more dates.  So if I have a better
> and more maintainable date parser, it would make sense to replace
> parsedate with it, get a step closer to eliminating a yacc dependency, and
> get rid of 900-odd lines of code that I doubt any of us really want to
> maintain.

I'm using parsedate() in a standalone application called parsedate
(original, isn't it? ;-)) in a mail2news script, so I can predict whether
or not nnrpd is going to accept the date-header I'm feeding it. I only want
the two pieces of software to be the same though ;-)

I can provide you with some (maybe 20 or so) rejected dates, if you like. 

> I'm not sure what to do about all those articles that would be rejected,
> though.
> 
> I think that using the stricter parser in nnrpd for local posts is an
> obvious thing to do, in the "be strict in what we generate" department.  I
> wondered if it would be worth going a step further and using a strict
> parser that doesn't permit the obsolete syntax of RFC 2822, but I'm
> guessing that would catch a lot of news readers that are doign things they
> shouldn't (like using GMT as the time zone instead of +0000, which is very
> common) and basically just cause headaches for people.  But it looks like
> using it for innd is a trickier question.

I think innd should use the old parsedate for some time to come. nnrpd
could use the stricter version (maybe configurable at compile time). First
I'd like to see some statistics on the software generating the illegal date
headers though.

- -- 
Erik Hensema (erik@hensema.net)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD4DBQE9dJBvuNWfqpFSu/cRAjOUAJ9I9SubC3WtpUfix9F7KQwD1JwqEACYylVo
Vri9Aeov4B8U6Q+SHIecQQ==
=PhLU
-----END PGP SIGNATURE-----