On Tue, Jul 15, 2003 at 01:56:53PM +1000, Iain Truskett wrote:
> * Ben Bennett ([EMAIL PROTECTED]) [15 Jul 2003 13:10]:
[...]
>
> 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.
Ok. I will think about that (suggestions welcomed).
> Sounds good. Ignoring unknown day names?
I think so. I haven't decided yet.
> > 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+/?
Perhaps, I will play with it when the rest is finished. Input from
people who speak other languages would be appreciated. I think that
would be okay in French, I am a bit concerned about how it behaves
with non-Latin languages.
> > 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".
Erm... maybe later I will make something that can deal with ambiguous
locales. That seems like a non-Simple.pm task (I realize that it
isn't that hard to do, but may be slow).
> 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 you have the locale then I think you should be able to assume
ordering.
> 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.
See above.
-ben
