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.

I don't see how you arrive at this conclusion. When I modify the input dates to read 200 and 205 respectively, the program crashes. When I modify the dates to be 2000 and 2005 respectively, the program completes properly.

This program shows how the year is handled:

use strict;
use warnings;
use Time::Piece;

my $t2 = localtime;
print "Time is $t2\n";
print "Year is ", $t2->year, "\n";
[download]

The output of that is

Time is Tue Dec 13 22:57:39 2005
Year is 2005
[download]

That is as expected.

The documentation for Time::Piece shows these two methods:

$t->year                # based at 0 (year 0 AD is, of course 1 BC)
$t->_year               # year minus 1900
[download]

I think it's clear that $t->year is simply the "zero" based year as we know them, and the $t->_year method is the year as we get it from the localtime function.