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.
This commit is contained in:
parent
b00513636c
commit
42bc60ead3
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue