I know you can mix them, but I would prefer to match completely since
as I said there is a decent speed win.

The fact that multiple formats can match is irrelevant here (that is
dealt with when filtering by type).  It might be useful to someone to
be able to get the parts of the given string back in a hash so that
they can see what pieces were not specified (in the case of a reduced
format).  Also in the case of Time only formats, it is a bit of a hack
to massage them into a DateTime, so it may be more useful to get the
parsed pieces back to use in another way.

Also the recurrence format Rn/PnYnMnDTnHnMnS is tricky since the start
date and time are not specified.  I plan on handling that the same way
that I do with the time components and using the date the user passed
in or DT->now() if none was specified...  However, I may want to get
at the parts of the recurrence from the calling code.

                -ben

On Wed, Jun 25, 2003 at 07:04:05AM -1000, Joshua Hoblitt wrote:
> On Wed, 25 Jun 2003, Ben Bennett wrote:
> 
> > All true... but my benchmarking as I wrote my ISO8601 showed that the
> > speed gained by pre-filtering by length to reduce the number of
> > regexps that need to be tried is substantial.
> 
> You can mix length with no-length specrefs.
> 
> > The other thing that my ISO8601 parser does is (optionally) return the
> > format specification and pieces of the time string (because it is not
> > always possible to cleanly map an ISO8601 string into a DT, but the
> > module tries its best).  Is there a way to easily do that with Builder
> > that I haven't spotted yet?
> 
> Theres only 6 strings that can match either dates or time.
> 
>     hhmmss
>     hhmm
>     hh
>     -mmss
>     -mm
>     --ss
> 
> -J
> 
> --

Reply via email to