closes bpo-29275: Remove Y2K reference from time module docs (GH-17321)

The Y2K reference is not needed as it only points out that Python's use
of C standard functions doesn't generally suffer from Y2K issues; the
point regarding conventions for conversion of 2-digit years in
:func:`strptime` is still valid.
(cherry picked from commit 42bc60ead39c7be9f6bb7329977826e962f601eb)

Co-authored-by: Callum Ward <wards.callum@gmail.com>

diff --git a/Doc/library/time.rst b/Doc/library/time.rst
index 17f8cfc5461473204b03829d157b13d1cbd5dcdc..c0f336fcbe429876fc2b2c0269974af29469d0a2 100644 (file)
--- a/Doc/library/time.rst
+++ b/Doc/library/time.rst
@@ -42,17 +42,12 @@ An explanation of some terminology and conventions is in order.
   library; for 32-bit systems, it is typically in 2038.
 
 .. index::
-   single: Year 2000
-   single: Y2K
+   single: 2-digit years
 
-.. _time-y2kissues:
-
-* **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.  Function :func:`strptime`
-  can parse 2-digit years when given ``%y`` format code.  When 2-digit years are
-  parsed, they are converted according to the POSIX and ISO C standards: values
-  69--99 are mapped to 1969--1999, and values 0--68 are mapped to 2000--2068.
+* Function :func:`strptime` can parse 2-digit years when given ``%y`` format
+  code. When 2-digit years are parsed, they are converted according to the POSIX
+  and ISO C standards: values 69--99 are mapped to 1969--1999, and values 0--68
+  are mapped to 2000--2068.
 
 .. index::
    single: UTC