Message134507
time.rst:
* **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.
.. class:: struct_time (...) A year value will be handled as described under :ref:`Year 2000 (Y2K) issues <time-y2kissues>` above.
.. [#] The use of ``%Z`` is now deprecated, but the ``%z`` escape that expands to the
preferred hour/minute offset is not supported by all ANSI C libraries. Also, a
strict reading of the original 1982 :rfc:`822` standard calls for a two-digit
year (%y rather than %Y), but practice moved to 4-digit years long before the
year 2000. The 4-digit year has been mandated by :rfc:`2822`, which obsoletes
:rfc:`822`.
Are these 3 notes still valid? It looks like struct_time note is wrong: the year 70 is now 70 and not interpreted as 1970 anymore.
---
timemodule.c:
PyDoc_STRVAR(module_doc,
"...
The tuple items are:\n\
year (four digits, e.g. 1998)\n\
...")
=> That's wrong. Example: time.gmtime(-55582200000).tm_year gives 208.
---
/home/haypo/prog/HG/cpython/Modules/timemodule.c: In function 'PyInit_time':
/home/haypo/prog/HG/cpython/Modules/timemodule.c:872: warning: unused variable 'p' |
|
Date |
User |
Action |
Args |
2011-04-26 22:09:23 | vstinner | set | recipients:
+ vstinner, belopolsky |
2011-04-26 22:09:23 | vstinner | set | messageid: <1303855763.43.0.366677912188.issue11930@psf.upfronthosting.co.za> |
2011-04-26 22:09:22 | vstinner | link | issue11930 messages |
2011-04-26 22:09:22 | vstinner | create | |
|