From dbf7956e522164518179be6682c74205fda2c7fe Mon Sep 17 00:00:00 2001
From: Guido van Rossum <guido@python.org>
Date: Tue, 25 Aug 1998 14:44:49 +0000
Subject: Clarify Y2K behavior when a tuple with a 2-digit date is passed to
 mktime() and such.

---
 Doc/lib/libtime.tex | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/Doc/lib/libtime.tex b/Doc/lib/libtime.tex
index f63ecb0..6cab3a9 100644
--- a/Doc/lib/libtime.tex
+++ b/Doc/lib/libtime.tex
@@ -26,9 +26,22 @@ determined by the C library; for \UNIX{}, it is typically in 2038.%
 \index{Year 2038}
 
 \item
-Year 2000 (Y2K) issues: Python depends on the platform's C library,
+\strong{Year 2000 (Y2K) issues}: Python depends on the platform's C library,
 which generally doesn't have year 2000 issues, since all dates and
-times are represented internally as seconds since the epoch.%
+times are represented internally as seconds since the epoch.
+Functions accepting a time tuple (see below) generally require a
+4-digit year.  For backward compatibility, 2-digit years are supported
+if the module variable \code{accept2dyear} is a non-zero integer; this
+variable is initialized to \code{1} unless the environment variable
+\code{PYTHONY2K} is set to a non-empty string, in which case it is
+initialized to \code{0}.  Thus, you can set \code{PYTHONY2K} in the
+environment to \code{x} to require 4-digit years for all year input.
+When 2-digit years are accepted, they are converted according to the
+POSIX or X/Open standard: values 69-99 are mapped to 1969-1999, and
+values 0--68 are mapped to 2000--2068.  Values 100--1899 are always
+illegal.  Note that this is new as of Python 1.5.2(a2); earlier
+versions, up to Python 1.5.1 and 1.5.2a1, would add 1900 to year
+values below 1900.%
 \index{Year 2000}%
 \index{Y2K}
 
-- 
cgit v0.12

