FAQ 4.18 Does Perl have a Year 2000 or 2038 problem? Is Perl Y2K compliant?
 

This is an excerpt from the latest version perlfaq4.pod, which
comes with the standard Perl distribution. These postings aim to
reduce the number of repeated questions as well as allow the community
to review and update the answers. The latest version of the complete
perlfaq is at http://faq.perl.org .

--------------------------------------------------------------------

4.18: Does Perl have a Year 2000 or 2038 problem? Is Perl Y2K compliant?

(contributed by brian d foy)

Perl itself never had a Y2K problem, although that never stopped people
from creating Y2K problems on their own. See the documentation for
"localtime" for its proper use.

Starting with Perl 5.11, "localtime" and "gmtime" can handle dates past
03:14:08 January 19, 2038, when a 32-bit based time would overflow. You
still might get a warning on a 32-bit "perl":

% perl5.11.2 -E 'say scalar localtime( 0x9FFF_FFFFFFFF )'
Integer overflow in hexadecimal number at -e line 1.
Wed Nov 1 19:42:39 5576711

On a 64-bit "perl", you can get even larger dates for those really long
running projects:

% perl5.11.2 -E 'say scalar gmtime( 0x9FFF_FFFFFFFF )'
Thu Nov 2 00:42:39 5576711

You're still out of luck if you need to keep track of decaying protons
though.



--------------------------------------------------------------------

The perlfaq-workers, a group of volunteers, maintain the perlfaq. They
are not necessarily experts in every domain where Perl might show up,
so please include as much information as possible and relevant in any
corrections. The perlfaq-workers also don't have access to every
operating system or platform, so please include relevant details for
corrections to examples that do not work on particular platforms.
Working code is greatly appreciated.

If you'd like to help maintain the perlfaq, see the details in
perlfaq.pod.