Dave Rolsky wrote:
On Tue, 14 Jul 2009, Rick Measham wrote:
This release depends on DateTime::Locale 0.43 and the locale tests
expect the data provided by that module. This isn't future-proof, but
Dave says that the methods that provide the %x, %X and %c patterns to
strftime are deprecated. Once the target stops moving, I'll try to
future proof these tests.
I'm not sure what you mean by stops moving. You don't want to wait until
I remove the methods, then Strptime will break altogether!
I'll consider the target to have stopped moving as soon as you've
decided which methods are going to carry on existing and which are going
away ..
At the moment those methods exists and are being used (by me, and
possibly by other people who use the Locale modules). Therefore my bug
report stands. If you're going to remove methods from objects, please do
so very slowly and discuss on this list first -- after all, you're
removing backward compatibility.
Once you fix the bug, I'll get the tests to work as it should. The
problem became clear when the data I got from strftime didn't parse
using strptime. Ideally the two methods should be symmetrical.
At the moment, strftime('%x') correctly returns 2009 (in en_US) as the
CLDR pattern is 'y'. But the cldr->strf converter is specifying %y. When
strptime sees %y, it expects two digits and so takes the '20' as the year.
If the methods are going away, I guess I can put the conversion into
Strptime. It just seems to make more sense to have it live near data.
Once you remove it, if you want the str[fp]time pattern for a locale,
you'll have to use DT:F:Strptime.
(Maybe you could move it into DateTime::Format::Locale to turn the
locale patterns into various formats including Str[fp]time?)
As far the locale data, that target will never stop moving. I'll keep
releasing new versions as the CLDR folks update their data.
Well .. yeah
Cheers!
Rick Measham
--
Message protected for iSite by MailGuard: e-mail anti-virus, anti-spam and
content filtering.
http://www.mailguard.com.au
