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.

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.

Hi there,

In the original example, the behaviour would arise from the strptime() call -- on most systems this ends up being a call to the strptime function in your local C library.

As it so happens, you were using %Y in your call which means the year, including the century (i.e. 4 digit year for us mortals).

On the other hand, had you used %y, it is defined thusly:

%y
    is the year within century. When a century is not otherwise specif
+ied, values in the range 69-99 refer to years in the twentieth centur
+y (1969 to 1999 inclusive); values in the range 00-68 refer to years 
+in the twenty-first century (2000 to 2068 inclusive). Leading zeros a
+re permitted but not required.
[download]

That's the source of the difference of opinion.

Cheers,
Matt