Date parse in perl

Russ Allbery rra at stanford.edu
Mon Apr 19 19:38:17 UTC 2004


Christoph Biedl <cbiedl at gmx.de> writes:

> Back to your problem:
> Today I'd rather spend the time to understand the mechanisms of how to
> embed C modules in Perl modules in order to reuse lib/parsedate.c. This
> would also ensure that this module behaves exactly like INN. Any
> volunteers?

If you want to parse any random date anyone's come up with, you don't want
to use parsedate.y; you want to use getdate.y from the CVS distribution
(and other places) with is a substantially expanded version of parsedate.y
(but now covered under the GPL).

If you only want to parse valid dates for Usenet articles, which is a
different problem, you want lib/date.c and the parsedate_rfc2822 function
there.  RFC 1036 has a bunch of random nonsense in it about dates, but in
practice actually defers to the mail standards, which means that RFC 2822
is canonical.  Experimental evidence shows that a slightly lax RFC 2822
parser will parse essentially every date seen on Usenet other than a few
completely mangled dates generated by spam programs that nothing can
parse.

It's on my list to finish the additional bits of laxness needed (mostly
coping with dates with invalid or missing time zones), add that to
lib/date.c, and then eliminate parsedate.y entirely, because embedding a
yacc parser causes all sorts of annoying problems and will cause even more
if we ever have threading.  Not to mention that the last time I checked, I
believe I found valid (obsolete syntax) dates that parsedate.y couldn't
parse.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.


More information about the inn-workers mailing list