From: Michael G. Schwern <schwern@pobox.com>
Date: Fri, 19 Sep 2008 21:46:48 +0000 (-0700)
Subject: We are no longer slaves to the vagaries of time_t.
X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=65a38213a55474ae493d2619f0ad5b8a4179b879;p=p5sagit%2Fp5-mst-13.2.git

We are no longer slaves to the vagaries of time_t.
---

diff --git a/lib/Time/Local.pm b/lib/Time/Local.pm
index b83bb1a..e5c4f88 100644
--- a/lib/Time/Local.pm
+++ b/lib/Time/Local.pm
@@ -272,16 +272,6 @@ absolute four digit year instead.
 The scheme above allows interpretation of a wide range of dates,
 particularly if 4-digit years are used.
 
-=head2 Limits of time_t
-
-The range of dates that can be actually be handled depends on the size
-of C<time_t> (usually a signed integer) on the given
-platform. Currently, this is 32 bits for most systems, yielding an
-approximate range from Dec 1901 to Jan 2038.
-
-Both C<timelocal()> and C<timegm()> croak if given dates outside the
-supported range.
-
 =head2 Ambiguous Local Times (DST)
 
 Because of DST changes, there are many time zones where the same local
@@ -304,17 +294,6 @@ for the "Europe/Paris" time zone, the local clock jumped from
 If the C<timelocal()> function is given a non-existent local time, it
 will simply return an epoch value for the time one hour later.
 
-=head2 Negative Epoch Values
-
-Negative epoch (C<time_t>) values are not officially supported by the
-POSIX standards, so this module's tests do not test them. On some
-systems, they are known not to work. These include MacOS (pre-OSX) and
-Win32.
-
-On systems which do support negative epoch values, this module should
-be able to cope with dates before the start of the epoch, down the
-minimum value of time_t for the system.
-
 =head1 IMPLEMENTATION
 
 These routines are quite efficient and yet are always guaranteed to