in reply to Time::Piece strangeness take two

Did you really mean to use the date 31st January 200 ?


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^2: Time::Piece strangeness take two
by jdporter (Paladin) on Dec 13, 2005 at 03:29 UTC

    Time::Piece is interpreting the year not as 200, but as 2100, i.e. 1900+200.
    (That is, of course, beyond the range of unix time, but that's no excuse...)

    We're building the house of the future together.

      No, BrowserUK is right; the first date is incorrect. If you notice, the second date contains the year 2005, which is how Time::Piece requires it. When I added another zero to the first date's year, I got the desired output.

        Sorry to have to argue, but a year of 200 (which is what the bad data contains) is interpreted by Time::Piece as 2100, as you can clearly see in the output. It does this because it's kind of a standard in the unix/C world (see gmtime, for example). Surely the fault is the bad data; but let's be straight about how Time::Piece is interpreting that bad data.

        We're building the house of the future together.
Re^2: Time::Piece strangeness take two
by kulls (Hermit) on Dec 13, 2005 at 03:27 UTC
    I agree with "InfiniteLoop". Whether we are passing valid date or something else, but Time::Piece must validate the date before processing it.
    -kulls
Re^2: Time::Piece strangeness take two
by InfiniteLoop (Hermit) on Dec 13, 2005 at 13:51 UTC
    Not really. Stumbled upon this bug, when the user modified the date and forgot to add the '5'. I guess I will stick with eavl{}ing the comparision. Thanks.