Update some docs to explain that Perl no longer has a 2038 bug.

1 files changed, 14 insertions, 6 deletions

diff --git a/pod/perlfaq4.pod b/pod/perlfaq4.pod
index 3200e7aca4..326ec9180b 100644
--- a/pod/perlfaq4.pod
+++ b/pod/perlfaq4.pod
@@ -516,12 +516,11 @@ Can you use your pencil to write a non-Y2K-compliant memo?  Of course
 you can.  Is that the pencil's fault?  Of course it isn't.
 
 The date and time functions supplied with Perl (gmtime and localtime)
-supply adequate information to determine the year well beyond 2000
-(2038 is when trouble strikes for 32-bit machines).  The year returned
-by these functions when used in a list context is the year minus 1900.
-For years between 1910 and 1999 this I<happens> to be a 2-digit decimal
-number. To avoid the year 2000 problem simply do not treat the year as
-a 2-digit number.  It isn't.
+supply adequate information to determine the year well beyond 2000 and
+2038.  The year returned by these functions when used in a list
+context is the year minus 1900.  For years between 1910 and 1999 this
+I<happens> to be a 2-digit decimal number. To avoid the year 2000
+problem simply do not treat the year as a 2-digit number.  It isn't.
 
 When gmtime() and localtime() are used in scalar context they return
 a timestamp string that contains a fully-expanded year.  For example,
@@ -534,6 +533,15 @@ not the language.  At the risk of inflaming the NRA: "Perl doesn't
 break Y2K, people do."  See http://www.perl.org/about/y2k.html for
 a longer exposition.
 
+=head2 Does Perl have a Year 2038 problem?
+
+No, all of Perl's built in date and time functions and modules will
+work to about 2 billion years before and after 1970.
+
+Many systems cannot count time past the year 2038.  Older versions of
+Perl were dependent on the system to do date calculation and thus
+shared their 2038 bug.
+
 =head1 Data: Strings
 
 =head2 How do I validate input?