But perhaps for edification:
$date =~ /\b(\d{4})(\d{2})(\d{2})\b/;
print "$1 $2 $3";
Will print ya "2003 03 11"
Simple if statement will determine what month in word format $2 is!
---
"There is more in heaven and earth
than is dreamt of in your philosophy" | [reply]
[d/l] |
Don't use a regex. Use the numerous Date:: modules on CPAN. Some examples would be Date::Manip and Date::Calc.
------
We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement. Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified. | [reply] |
I really don't see what is wrong with using a regex for solving this problem, the date is a string of numbers and regex are perfectly fine for matching strings of numbers. There is no need to reach for Date::Manip to just hunt through a log file for entries in March as an example.
By all means point out that the poster should look at the CPAN Date:: modules if they are doing more complex date operations but I would guess that a link to perlman:perlre would probably be more useful at this stage.
--
Life is a tale told by an idiot -- full of sound and fury, signifying nothing. William Shakespeare, Macbeth
| [reply] |
In my experience (which is not the sum totality of existence), once you start down a way of doing things, you tend to stick with it, and you always have to do more complicated things. Just as you said, Date::* is better for more complex things. Right now, you're right in that a regex would probably be just fine. If this wasn't code for production use, I would probably also use a regex.
However, in my advice, I always assume (unless otherwise noted) that the poster is asking about code that will eventually end up in production use. Unless you're someone like japhy, Abilgail-II, or tye, I would not recommend using regexes to parse irregular formats in production code. (And, yes, dates are irregular formats, regardless of whether you know where it's coming from. You might know today, but you don't know about tomorrow.)
------
We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement. Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.
| [reply] |