* Ben Bennett ([EMAIL PROTECTED]) [15 Jul 2003 13:10]:
> I am taking a whack at DT::F::Simple (please speak up now if anyone
> else wants to claim this project) that can parse things that are
> similar to the ones that Date::Parse can do.
I was going to do it, but probably wouldn't get around to it for quite
some time, so it's probably good you have.
My quibble; the name. I'm not a huge fan of ::Simple and ::Lite.
Unfortunately, I can't think of a nice alternate for it.
> Namely:
> - Rough ISO8601 strings (only complete datetimes and dates)
> - Dates with '-', '.', or '/' separators (either by month number or
> localized short or long name)
> - Times with ':' or '-' separator and optional localized AM/PM
> - Day names will be used to sanity check the parsed date if present
Sounds good. Ignoring unknown day names?
> - I will use localized BC/AD if present
> Ommissions from Date::Parse:
> - July 14th will not be parsed (I don't have localized info on the
> numeric suffixes)
How about you just assume /\d{1,2}\w+/?
> This will use the DT::F::Locales to get the localized forms of the
> days and months.
What happens in the event of input being in an unknown locale? As in "we
don't know what locale this is in" rather than "we don't have locale
data for xy_XX".
> Which leads to my problem, there appears to be no simple way to get
> the date order to differentiate m/d/y from d/m/y.
Not really. The best one can do is have it so dates that can only be one
type and not the other are done correctly. Ambiguity is part of the
reason ISO8601 and W3CDTF have their order specified and why rfc(2)822
uses the month _name_.
If "Simple" is to be simple, I'm not sure it can really handle such
things. The idea of "Simple" modules is to have as little of an
interface as possible. Inner complexity and outer simplicity.
cheers,
--
Iain.
