At 8:30 AM +0200 5/22/08, H.Merijn Brand wrote:
>On Wed, 21 May 2008 22:29:13 -0500, "John E. Malmberg" <[EMAIL PROTECTED]>
>wrote:
>
>> A todo for VMS:
>>
>> In [EMAIL PROTECTED], 07arith.t is dying on test 11.
>>
>> From the comments, it seems that it is expecting the _strptime function
>> (or something) to convert '2001-2-29' to '2001-3-1'.
>
>It's like this since a long time on all HP-UX too, and Steve P traced
>it to be some XS problem last night.
>
>Matt did not (yet) reply to my mails.
>
>> Instead it is failing with the message "Error parsing time at
> > ../lib/Time/Piece.pm line 615, <DATA> line 17.
I noticed this too. On VMS it boils down to passing to strptime a
time string for 29 February 2001, but unless I've lost some time
myself, 2001 was not a leap year, so it's not a valid time. The
standard for strptime is silent about what level of validation, if
any, should be done on the incoming time string.
Here's VMS:
$ perl -MTestInit -"MTime::Piece" -"E" "say join '|',
Time::Piece::_strptime('2001-2-29 12:34:56', '%Y-%m-%d %H:%M:%S');"
Error parsing time at -e line 1.
Here's Mac OS X:
% ./perl -MTestInit -"MTime::Piece" -E "say join '|',
Time::Piece::_strptime('2001-2-29 12:34:56', '%Y-%m-%d %H:%M:%S');"
56|34|12|1|2|101|4|59|0|0|0
If I'm reading this right, Mac OS X (and probably other BSDs) is
interpreting this as the first of March, which doesn't make much
sense to me, but may have a rationale behind it. In any case,
Time::Piece seems to depend on this non-portable behavior, and even,
as John noted, to be specifically testing for it.
--
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
