Re: [ANNOUNCE] DateTime::Format::Strptime 1.1000
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
Re: [ANNOUNCE] DateTime::Format::Strptime 1.1000
Dave Rolsky wrote: As far the locale data, that target will never stop moving. I'll keep releasing new versions as the CLDR folks update their data. and I, for one, thank you for it. Tea is on me the next time we manage to be in the same space at the same time. -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing DirectorFax: +1 763 786-8180 ApTest MinnesotaInet: sh...@aptest.com
Re: [ANNOUNCE] DateTime::Format::Strptime 1.1000
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! As far the locale data, that target will never stop moving. I'll keep releasing new versions as the CLDR folks update their data. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
[ANNOUNCE] DateTime::Format::Strptime 1.1000
This release allows the 'pattern' to be a regex. This is handy for situations like: pattern => '%Y-%m-%d[T ]%H:%M:%S' where you'll accept either the 'T' or space delimiter in ISO8601 type datetimes. 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. The release will be available from CPAN shortly, or you can download it from Google Code: http://datetime-format-strptime.googlecode.com/files/DateTime-Format-Strptime-1.1000.tgz Cheers! Rick Measham -- Message protected for iSite by MailGuard: e-mail anti-virus, anti-spam and content filtering. http://www.mailguard.com.au