Re: [Boost-users] [date_time] extract date from string using a list of patterns

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-06-27 11:17:48

Jason Dolan wrote:
> Jeff Garland wrote:
>> Jason Dolan wrote:
>>> I'm looking to take a string and convert it to a date.  The only problem 
>>> is the string can be one of many patterns. i.e. ("%Y%m%d", "%Y-%m-%d", 
>>> "%d/%m/%Y", etc...).  It is also possible that the given string will 
>>> fail all pattern matches, and thus return false.
>> And there's nothing to indicate which pattern it might be?
> Nope.  I'm basically allowing the user to input a date and time *almost* 
> anyway they want.  What I want to do is test that string against my list 
> of patterns(i.e. known ways to write a date and time) to try and parse 
> the date.

Well, again some of them are going to be ambiguous.  And I'll just say, this 
is a big (read not doable) undertaking.  Are all these valid?  They certainly 
are to someone somewhere:

   june 5 2006
   june 5, 2006
   june 5, 06
   jun 5        //just assume the current year
   junio 5, 2006  //spanish
   5-jun-2006
   5-june-2006
   05-June-2006
   05    JUNE 2006
   7/5/6
   7/6/5
   5/6/7
   07/05/06
   05-07-06
   05.07.06
   050706

Now unless there is some other context you can bring to bear, like user 
validation, format preferences, or "should be around the current date" it's 
going to be impossible to get right.

> What I'm doing right now is:
> 
>... snip detail...
 >
> But I'm not sure if this is the right way to go about it.  Further, what 
>   happens if they just put in a time (it would make sense to assume it 
> is the current date), Can this handle a two digit year? I wouldn't think 
> so...

%y is a 2 digit year.  But again, you will run into serious problems with 
ambiguity.  What's this date?  05-06-07

As for the time, that just adds another level of complication.  Seems like you 
just want to ignore them not actually parse them.

> Besides that, each time the second SetDate function is called (which 
> will be once for each format for the worst case), I have to create a 
> time_input_facet object, a stringstream object and a pdate object. It 
> would be nice to have a function like this use less resources since it's 
> called so much.

You could refactor your code so you don't reallocate the stringstream and 
facet (just reset the strings and formats). But if you really need a high 
level of efficiency, then you're going to just have to bite the bullet and 
write a custom parser.  The iostreams solution will always be inherently less 
efficient than custom solutions.

Jeff