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

diff --git a/pod/perlfaq4.pod b/pod/perlfaq4.pod
index 3200e7a..326ec91 100644 (file)
--- 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?

diff --git a/pod/perlport.pod b/pod/perlport.pod
index f8fb1fe..8a72de2 100644 (file)
--- a/pod/perlport.pod
+++ b/pod/perlport.pod
@@ -641,9 +641,6 @@ The value for C<$offset> in Unix will be C<0>, but in Mac OS will be
 some large number.  C<$offset> can then be added to a Unix time value
 to get what should be the proper value on any system.
 
-On Windows (at least), you shouldn't pass a negative value to C<gmtime> or
-C<localtime>.
-
 =head2 Character sets and character encoding
 
 Assume very little about character sets.
@@ -1863,7 +1860,7 @@ platforms.  See L<File::Glob> for portability information.
 
 =item gmtime
 
-Same portability caveats as L<localtime>.
+gmtime() has a range of about 2 billion years before and after 1970.
 
 =item ioctl FILEHANDLE,FUNCTION,SCALAR
 
@@ -1914,10 +1911,9 @@ Available on 64 bit OpenVMS 8.2 and later.  (VMS)
 
 =item localtime
 
-Because Perl currently relies on the native standard C localtime()
-function, it is only safe to use times between 0 and (2**31)-1.  Times
-outside this range may result in unexpected behavior depending on your
-operating system's implementation of localtime().
+localtime() has the same range as L<gmtime>, but because time zone
+rules change its accuracy for historical and future times may degrade
+but usually by no more than an hour.
 
 =item lstat