Re: timezone.el patterns in emacs 19.34

[Ken Raeburn <raeburn@cygnus.com>]

Hrvoje Niksic <hniksic@srce.hr> writes:

> > Besides, I think you'd probably wind up doing the regexp bit
> > anyways, just at the C level.  These patterns don't have to match
> > the *entire* string, just some substring.
> I would do no regexp matching.  If I had to resort to regexps, then I
> would rather leave it in Lisp, as it is.

Okay, so how would you get around the requirement of matching a
substring, without using regexps?  If you can do it, and get much
better performance than we've got now with the lisp code, great.  But
as I just indicated in other mail, my trivial little patch already
addresses the performance issue to some degree.  So you'll have to do
even better. :-)

And, by the way, if you do go ahead with this, I'd suggest returning
numbers instead of strings when practical.  They can be turned into
strings easily enough in lisp, and the gnus-dd-mmm usage just converts
them back to numbers and discards the strings, which means more
needless garbage to collect.  (Don't underestimate the cost of garbage
collection.  I've managed to speed up some code by tweaking it to
allocate less short-term heap storage.)

> NO!  I hate getdate.y.  First, because of the `.y' thingie. :-)

Aside from the substring issue, I think a parser would be well suited
to this task.  I see two advantages to it:
 * Tokenizes first, then looks for patterns in the tokens; this means
   any backtracking doesn't have to re-process every character.
 * Yacc sets up a FSM for matching multiple sequences in parallel (as
   do the more sophisticated regexp matchers), so if a match is going
   to be made, it'll be made in one pass; the hairy work is done at
   build time.
Certainly, yacc isn't the be-all and end-all of parsing technology, by
a long shot.  But it's up to this task.

>	  Then,
> there are copyright problems with it.

No, there aren't.  The version I'm looking at has a "public domain, no
copyright" label on it.  There would be no problem with incorporating
a copy into emacs.

>	  And, I'd like to have a fast
> routine that matches those 7 or so format strings.

Yes, that's the problem I see with it -- it'll handle more than we
want.  A date header saying "+23hours" is bogus, and should be treated
as such.  Though if getdate.y matches more "real" date formats than
timezone-parse-date, I don't think it would be a bad idea to support
them as well, since this is timezone-parse-date we're talking about,
and not gnus-parse-conforming-date-header.

Ken