Re: DateTime::Format::Strptime fails test
On Mon, 13 Jul 2009, Rick Measham wrote: I believe there's an error in DateTime::Locale::Base that is screwing with my fix. Line 277 turns the CLDR notation 'y' into the strftime notation '%y'. From my reading of http://www.unicode.org/reports/tr35/tr35-9.html#Date_Format_Patterns 'y' should become '%Y'. All those methods that convert to strftime patterns are deprecated and will go away in a future release, so even if I fixed this bug, if you're relying on them, your code will break eventually. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
RE: DateTime::Format::Strptime fails test
Dave, I'm not sure I understood your last post. Did you mean that those strftime methods only found in DateTime::Locale::Base are going away? Or did you mean that strftime methods in DateTime proper are being deprecated and removed? If yes to the later, is DateTime::Format::Strptime going away as well? Thanks, Bobby -Original Message- From: Dave Rolsky [mailto:auta...@urth.org] Sent: Monday, July 13, 2009 6:24 AM To: datetime Subject: Re: DateTime::Format::Strptime fails test On Mon, 13 Jul 2009, Rick Measham wrote: I believe there's an error in DateTime::Locale::Base that is screwing with my fix. Line 277 turns the CLDR notation 'y' into the strftime notation '%y'. From my reading of http://www.unicode.org/reports/tr35/tr35-9.html#Date_Format_Patterns 'y' should become '%Y'. All those methods that convert to strftime patterns are deprecated and will go away in a future release, so even if I fixed this bug, if you're relying on them, your code will break eventually. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
RE: DateTime::Format::Strptime fails test
All, I'm sorry all to reply to my own post. I should have read the original message first before replying to Dave's message. I see that the module I'm questioning is at the root of the issue, so my apologies again. As someone who uses DateTime::Format::Strptime quite a bit, what can one use to convert formats other than this method? Dave, May I ask why these are being removed? Bobby
RE: DateTime::Format::Strptime fails test
On Mon, 13 Jul 2009, Metz, Bobby wrote: I'm sorry all to reply to my own post. I should have read the original message first before replying to Dave's message. I see that the module I'm questioning is at the root of the issue, so my apologies again. As someone who uses DateTime::Format::Strptime quite a bit, what can one use to convert formats other than this method? All that's being deprecated are some methods in DateTime::Locale::Base. However, it looks like Strptime is using them, in which case I think the fix is to move the CLDR - strftime translation over to Strptime itself, where it will be maintained (because it's actually needed). May I ask why these are being removed? Because they're not needed for DateTime, which is the primary consumer of DateTime::Locale, and because DateTime::Locale gets all its data from CLDR, which unsurprisingly uses this CLDR formatting system ;) -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: DateTime::Format::Strptime fails test
Dave Rolsky wrote: All those methods that convert to strftime patterns are deprecated and will go away in a future release, so even if I fixed this bug, if you're relying on them, your code will break eventually. Erm .. I'm confused. DateTime::Locale will no longer provide the strftime patterns for %c, %x and %X? If not, how will those be generated? Cheers! Rick Measham -- Message protected for iSite by MailGuard: e-mail anti-virus, anti-spam and content filtering. http://www.mailguard.com.au
[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
Item #1 returned by STORABLE_freeze for DateTime is not a reference
Does Item #1 mean the first list element returned by STORABLE_freeze?
return $serialized, $self-{locale}, $self-{tz}, \$self-{formatter};
Because, indeed it isn't a reference, but a scalar.
I have some code that is serializing items that have DateTime objects
(of course) and I'm seeing that message when running
my test suite.
I added this line above that line above in DateTime:
warn $serialized\n;
And running my tests I see:
utc_rd_days:733603|utc_rd_secs:2927|rd_nanosecs:0|version:0.4401
utc_rd_days:733602|utc_rd_secs:2927|rd_nanosecs:0|version:0.4401
ok 6 - Fetched expected key
utc_rd_days:733603|utc_rd_secs:2927|rd_nanosecs:0|version:0.4401
utc_rd_days:733602|utc_rd_secs:2927|rd_nanosecs:0|version:0.4401
utc_rd_days:733603|utc_rd_secs:2927|rd_nanosecs:0|version:0.4401
utc_rd_days:733602|utc_rd_secs:2927|rd_nanosecs:0|version:0.4401
ok 7 - Fetched data matches
utc_rd_days:733603|utc_rd_secs:2927|rd_nanosecs:0|version:0.4401
(in cleanup) Item #1 returned by STORABLE_freeze for DateTime
is not a reference at ../../lib/Storable.pm (autosplit into
../../lib/auto/Storable/_freeze.al) line 339 during global
destruction, at line 327
Line 327 is
my $serialized = nfreeze( $data );
I'm a bit confused why it's only complaining on the last one --
STORABLE_freeze is seemingly returning the same (scalar) data.
It's expected that this nfreeze is happening in a DESTROY() (the data
gets serialized and stored upon destroy).
Is the destroy a red herring?
--
Bill Moseley
mose...@hank.org
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) */
Re: Item #1 returned by STORABLE_freeze for DateTime is not a reference
On Mon, July 13, 2009 6:13 pm, Bill Moseley wrote: (in cleanup) Item #1 returned by STORABLE_freeze for DateTime is not a reference at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/_freeze.al) line 339 during global destruction, at line 327 It's expected that this nfreeze is happening in a DESTROY() (the data gets serialized and stored upon destroy). Is the destroy a red herring? Order of destruction during global destruction isn't guaranteed; it's entirely possible there are important bits of Storable gone by the time your DESTROY is called. Arrange your scopes such that any important DESTROY happens before global destruction.
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
