* Synced the perlfaq

The latest commit in https://github.com/briandfoy/perlfaq is

    4e2e0c9bcb3404e0b09d2e61e23ba6a6095b1

dated Sat Dec 19 04:17:11 2009 -0600

1 files changed, 25 insertions, 30 deletions

diff --git a/pod/perlfaq4.pod b/pod/perlfaq4.pod
index df813da20c..8d5e2e6961 100644
--- a/pod/perlfaq4.pod
+++ b/pod/perlfaq4.pod
@@ -21,7 +21,7 @@ L<perlnumber> shows the gory details of number representations and
 conversions.
 
 To limit the number of decimal places in your numbers, you can use the
-printf or sprintf function.  See the L<"Floating Point
+C<printf> or C<sprintf> function.  See the L<"Floating Point
 Arithmetic"|perlop> for more details.
 
 	printf "%.2f", 10/3;
@@ -533,35 +533,30 @@ you'll still end up on the previous calendar day, although not at
 noon. Since you don't care about the time, the one hour difference
 doesn't matter and you end up with the previous date.
 
-=head2 Does Perl have a Year 2000 problem? Is Perl Y2K compliant?
-
-Short answer: No, Perl does not have a Year 2000 problem.  Yes, Perl is
-Y2K compliant (whatever that means). The programmers you've hired to
-use it, however, probably are not.
-
-Long answer: The question belies a true understanding of the issue.
-Perl is just as Y2K compliant as your pencil--no more, and no less.
-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.
-
-When gmtime() and localtime() are used in scalar context they return
-a timestamp string that contains a fully-expanded year.  For example,
-C<$timestamp = gmtime(1005613200)> sets $timestamp to "Tue Nov 13 01:00:00
-2001".  There's no year 2000 problem here.
-
-That doesn't mean that Perl can't be used to create non-Y2K compliant
-programs.  It can.  But so can your pencil.  It's the fault of the user,
-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 2000 or 2038 problem? Is Perl Y2K compliant?
+
+(contributed by brian d foy)
+
+Perl itself never had a Y2K problem, although that nevers stopped people
+from creating Y2K problems on their own. See the documentation for
+C<localtime> for its proper use.
+
+Starting with Perl 5.11, C<localtime> and C<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 C<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 C<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 tracking of decaying protons
+though.
 
 =head1 Data: Strings