Jason Dolan 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
Jeff Garland wrote: 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