DateTime does say: "This module does not parse dates!" so that's out.
I didn't spend time on Date::Manip because I keep reading posts that say to stop using it... But looking at the documentation now, it seems like it might be exactly what I'm looking for, so I'll give it a try. Thanks!
Edit: On closer examination, while Date::Manip::Date does support a wide variety of date formats for input, it uses the POSIX standard for date format strings in output, so doesn't really help after all. :-(
| [reply] |
Well, the DateTime module itself doesn't parse strings, but the DateTime family of modules does include DateTime::Format::ISO8601 and most of the Format modules will both parse to and pretty-print DateTime objects. The ISO8601 standard doesn't allow any old wierdness that someone might choose, but it does include most sensible formats.
| [reply] |
DateTime does say: "This module does not parse dates!" so that's out.
I use DateTime to parse dates (and times) all the time. However, usually I'm parsing some specific pre-defined format, such as the format used by a particular RDBMS, the format used in email headers, or the format found in Apache log files; there are corresponding DateTime::Format::Foo modules for a wide variety of these.
General-purpose "whatever format the user types" date parsing is a fundamentally intractable problem, because the user will type junk like "6/8", and without further context there is absolutely no way to know what they mean. The five most likely answers are probably (not necessarily in this order) June of 2008, June 8th of the current year, August 6th of the current year, June 8th in the adjacent year (coming year if it's past June 8th already, previous year otherwise), and August 6th in the adjacent year. When getting date input from users, the only really reasonable approach I've discovered so far is to ask for the year, the month, and the day, each in its own appropriately labeled field.
| [reply] |
