I personally think there are only two ways of dealing with a problem like this in advance:
- Don't Care.
Just ignore the problem and trust that it's not ever going to be an issue.
- Use a time format that doesn't have the limitation.
The bottom line is, you can represent a date as a string that has no limitations to how far in the future it can go -- but then you need something to parse those dates for doing calculations ... Date::Manip can handle any 4 digit year ... Date::Calc claims to work for dates up to at least the year "32767" (depending on the size of int for your platform) ... Presumably DateTime has been designed to not have any inherient limitations (so if you use it, you can trust that even if it's built on top of a "seconds since epoch" right now, eventually someone will change the implimentation later on) (yep .. i just checked, see update), etc...
I don't see a lot of middle ground on an issue like this.
If you're going to worry about it, worry about it all the way and make sure it works ... otherwise just put a conservative comment in the User Manual that says something like "Use this software with dates greater them 2010 at your own risk" and don't make a lot of work for yourself that may or may not acctually ever be usefull to someone who may or may not be looking at your code.
Update: DateTime works great...
laptop:~> perl -MDateTime -MDateTime::Duration -l -w
my $d = DateTime->now;
$d->add(years => 200);
print $d->iso8601();
^D
2203-04-11T06:52:55