Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the DateTime-Locale CPAN distribution.

Report information
The Basics
Id: 110244
Status: resolved
Priority: 0/
Queue: DateTime-Locale

People
Owner: Nobody in particular
Requestors: rt.cpan [...] sartak.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 1.01
Fixed in: 1.02



Subject: Is breakage of "en-us"(should be "en_US" or at least "en-US") intentional?
Hi Dave, We're getting reports that DateTime::Locale 1.01 breaks RT. Looks like "en-us" no longer loads a locale. I'm happy to ship releases to use the recommended "en_US" but I wanted to flag this in case it was inadvertent. perl -MDateTime::Locale -le 'print DateTime::Locale->VERSION; my $loc = DateTime::Locale->load("en-us"); print $loc; print $loc->datetime_format_long;' 0.45 DateTime::Locale::en=HASH(0x7fcab382ec90) MMMM d, y h:mm:ss a z perl -MDateTime::Locale -le 'print DateTime::Locale->VERSION; my $loc = DateTime::Locale->load("en-us"); print $loc; print $loc->datetime_format_long;' 1.01 Invalid locale code or name: en-us perl -MDateTime::Locale -le 'print DateTime::Locale->VERSION; my $loc = DateTime::Locale->load("en-US"); print $loc; print $loc->datetime_format_long;' 1.01 DateTime::Locale::FromData=HASH(0x7f949a845d50) MMMM d, y 'at' h:mm:ss a z
On Wed Dec 09 15:49:18 2015, SARTAK wrote: Show quoted text
> Hi Dave, > > We're getting reports that DateTime::Locale 1.01 breaks RT. Looks like > "en-us" no longer loads a locale. I'm happy to ship releases to use > the recommended "en_US" but I wanted to flag this in case it was > inadvertent. > > > perl -MDateTime::Locale -le 'print DateTime::Locale->VERSION; my $loc > = DateTime::Locale->load("en-us"); print $loc; print $loc-
> >datetime_format_long;'
> 0.45 > DateTime::Locale::en=HASH(0x7fcab382ec90) > MMMM d, y h:mm:ss a z > > > perl -MDateTime::Locale -le 'print DateTime::Locale->VERSION; my $loc > = DateTime::Locale->load("en-us"); print $loc; print $loc-
> >datetime_format_long;'
> 1.01 > Invalid locale code or name: en-us > > > perl -MDateTime::Locale -le 'print DateTime::Locale->VERSION; my $loc > = DateTime::Locale->load("en-US"); print $loc; print $loc-
> >datetime_format_long;'
> 1.01 > DateTime::Locale::FromData=HASH(0x7f949a845d50) > MMMM d, y 'at' h:mm:ss a z
Actually, the recommended form is now "en-US" with a dash, not an underscore. But there's no reason not to support lower case country/script/territory codes. They're not exactly correct, but if it used to work I can't see a really strong reason to break it. Just note that the module no longer preserves the original representation passed to ->load, so you if you ask for $locale->code you'll get 'en-US' back.
Hey Dave, Thank you for your quick response! On 2015-12月-09 水 15:54:30, DROLSKY wrote: Show quoted text
> Actually, the recommended form is now "en-US" with a dash, not an > underscore.
Yup, I saw the note in the CHANGES file (see my subject :)). I was mostly using "en-US" to show that the problem was case not underscore-vs-dash. Show quoted text
> But there's no reason not to support lower case > country/script/territory codes. They're not exactly correct, but if it > used to work I can't see a really strong reason to break it.
I appreciate that. Show quoted text
> Just note that the module no longer preserves the original > representation passed to ->load, so you if you ask for $locale->code > you'll get 'en-US' back.
That shouldn't be a problem for us. Thank you! Shawn