Dave Rolsky wrote:
> On Tue, 10 Jun 2003, Rick Measham wrote:
>
>> > Anyway, I've
>> > applied it mostly, except that for era I used "ACE" and "BCE", because
>> > I'm really not comfortable favoring one religion over another inside
>> > the core code.
>>
>> That's cool .. I imagine that we'll change it in short-order to get it
>> from the Locale .. which makes me think of something that Locale might
>> need ..
>
> Actually, I don't think so. Remember when I first looked at the ICU stuff
> and posted about the problem for the Taiwanese era. Without knowing the
> "year 0" for a locale's epoch, we can't use the epoch name.
Yes, the existing era information isn't useful ATM. I've left it in because
it has future potential. I'll make this clear in the docs.
>> $locale = new DateTime::Locale::en_AU;
>
> Actually, I'd expect something like
>
> DateTime::Locale->new( locale => 'en_AU' );
Well, its currently DateTime::Locale->load('en_AU') - that's preferred over
"new DateTime::Locale::en_AU;" because it caches the returned locale
object. Either are valid though.
If the consensus is the constructor might take extra arguments in the
future, I can adjust it to accept both of the following:
DateTime::Locale->load('en_AU');
DateTime::Locale->load(locale => 'en_AU');
>> $locale->eras();
>> # returns ('BCE' and 'ACE')
>>
>> $locale->eras('BC', 'AD');
>> # returns ('BC' and 'AD') and sets these in the $locale (but not
>> DT::Locale::en_AU)
>
> I really think locales need to be immutable, or else users could get
> really confused if they don't notice that set line.
Yes, there are loads of features that could be added, but I think it should
be KISS if possible.
> You're always welcome to provide a custom subclass like 'en_AU_RM' ;)
Yes, that's why the language_territory_variant locales exist, and I'd bung
them in a different @INC path to make it absolutely clear that they are
custom locales.
Cheers,
Rich
--
Richard Evans
[EMAIL PROTECTED]
