Remove time.accept2dyear #56139

abalkin · 2011-04-26T19:37:42Z

BPO	11930
Nosy	@abalkin, @vstinner
Files	remove-accept2dyear.diff datetime_y2k.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2011-05-02.17:17:26.562>
created_at = <Date 2011-04-26.19:37:41.759>
labels = ['extension-modules', 'type-feature', 'library']
title = 'Remove time.accept2dyear'
updated_at = <Date 2011-05-02.21:04:16.168>
user = 'https://github.com/abalkin'

bugs.python.org fields:

activity = <Date 2011-05-02.21:04:16.168>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2011-05-02.17:17:26.562>
closer = 'belopolsky'
components = ['Extension Modules', 'Library (Lib)']
creation = <Date 2011-04-26.19:37:41.759>
creator = 'belopolsky'
dependencies = []
files = ['21785', '21788']
hgrepos = []
issue_num = 11930
keywords = ['patch']
message_count = 13.0
messages = ['134493', '134507', '134508', '134509', '134512', '134516', '134517', '134520', '134933', '134988', '134993', '134996', '135008']
nosy_count = 3.0
nosy_names = ['belopolsky', 'vstinner', 'python-dev']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue11930'
versions = ['Python 3.3']

abalkin · 2011-04-26T19:37:40Z

As implemented in bpo-10827, use of 2-digits years in timetuples to mean 4-digit years straddling year 2000 is deprecated in 3.3. There is no mechanism for issuing deprecation warning for access to a module variable, but a deprecation note was added to its documentation.

Attached patch removes time.accept2dyear and the associated behaviors.

vstinner · 2011-04-26T22:09:23Z

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'

abalkin · 2011-04-26T22:13:34Z

On Tue, Apr 26, 2011 at 6:09 PM, STINNER Victor <[email protected]> wrote:

It looks like struct_time note is wrong: the year 70 is now 70 and not interpreted as 1970 anymore.

What makes you say so?

1970

abalkin · 2011-04-26T22:20:56Z

On Tue, Apr 26, 2011 at 6:09 PM, STINNER Victor <[email protected]> wrote:
..

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.

This is wrong regardless of this patch. I don't mind fixing this,
but it would be a different issue. Can you suggest a change? I would
like the docstring to still inform the user that 1998 should be given
as 1998 and not as 98. Maybe s/four/all/?

vstinner · 2011-04-26T22:30:24Z

"What makes you say so?

1970"

Don't write ">>> " using the email interface :-)

--

>>> t
time.struct_time(tm_year=70, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=0)
>>> time.mktime(t)
-59958144561.0
>>> time.localtime(_)
time.struct_time(tm_year=70, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=2, tm_yday=1, tm_isdst=0)

Year 70 is considered as the year 70.

abalkin · 2011-04-26T22:42:32Z

On Tue, Apr 26, 2011 at 6:30 PM, STINNER Victor <[email protected]> wrote:
>
> STINNER Victor <[email protected]> added the comment:
>
> "What makes you say so?
>
> 1970"
>
> Don't write ">>> " using the email interface :-)
>

Sorry. That was the output of time.strptime('70', '%y')[0].

abalkin · 2011-04-26T22:52:18Z

On Tue, Apr 26, 2011 at 6:09 PM, STINNER Victor <[email protected]> wrote:
..

.. class:: struct_time (...) A year value will be handled as described under :ref:`Year 2000 (Y2K) issues <time-y2kissues>` above.

This one needs to be removed. Thanks.

vstinner · 2011-04-26T23:30:06Z

The next step is to update the datetime module: something like the attached patch (datetime_y2k.patch).

vstinner · 2011-05-01T22:04:17Z

Le mardi 26 avril 2011 à 22:20 +0000, Alexander Belopolsky a écrit :

Alexander Belopolsky <[email protected]> added the comment:

On Tue, Apr 26, 2011 at 6:09 PM, STINNER Victor <[email protected]> wrote:
..
>
> 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.

This is wrong regardless of this patch. I don't mind fixing this,
but it would be a different issue. Can you suggest a change? I would
like the docstring to still inform the user that 1998 should be given
as 1998 and not as 98. Maybe s/four/all/?

"year (e.g. 1998)\n" is enough.

python-dev · 2011-05-02T16:31:47Z

New changeset e6f6ac8c2502 by Alexander Belopolsky in branch 'default':
Issue bpo-11930: Remove deprecated time.accept2dyear.
http://hg.python.org/cpython/rev/e6f6ac8c2502

python-dev · 2011-05-02T17:14:48Z

New changeset db2ac3dc6cc2 by Alexander Belopolsky in branch 'default':
Issue bpo-11930: Remove year >= 1000 limitation from datetime.strftime.
http://hg.python.org/cpython/rev/db2ac3dc6cc2

python-dev · 2011-05-02T18:15:13Z

New changeset bfd741162741 by Alexander Belopolsky in branch 'default':
Issue bpo-11930: Added Misc/NEWS and versionchanged entries.
http://hg.python.org/cpython/rev/bfd741162741

vstinner · 2011-05-02T21:04:16Z

New changeset e6f6ac8c2502 by Alexander Belopolsky in branch 'default':
Issue bpo-11930: Remove deprecated time.accept2dyear.

Great!

abalkin added the type-feature A feature request or enhancement label Apr 26, 2011

abalkin added extension-modules C modules in the Modules dir stdlib Python modules in the Lib dir labels May 2, 2011

abalkin closed this as completed May 2, 2011

ezio-melotti transferred this issue from another repository Apr 10, 2022

serhiy-storchaka mentioned this issue Jun 20, 2024

datetime.strftime("%Y") is not padding correctly #120713

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Remove time.accept2dyear #56139

Remove time.accept2dyear #56139

abalkin commented Apr 26, 2011

abalkin commented Apr 26, 2011

Uh oh!

vstinner commented Apr 26, 2011

Uh oh!

abalkin commented Apr 26, 2011

Uh oh!

abalkin commented Apr 26, 2011

Uh oh!

vstinner commented Apr 26, 2011

Uh oh!

abalkin commented Apr 26, 2011

Uh oh!

abalkin commented Apr 26, 2011

Uh oh!

vstinner commented Apr 26, 2011

Uh oh!

vstinner commented May 1, 2011

Uh oh!

python-dev mannequin commented May 2, 2011

Uh oh!

python-dev mannequin commented May 2, 2011

Uh oh!

python-dev mannequin commented May 2, 2011

Uh oh!

vstinner commented May 2, 2011

Uh oh!

Uh oh!

Remove time.accept2dyear #56139

Remove time.accept2dyear #56139

Comments

abalkin commented Apr 26, 2011

abalkin commented Apr 26, 2011

Uh oh!

vstinner commented Apr 26, 2011

Uh oh!

abalkin commented Apr 26, 2011

Uh oh!

abalkin commented Apr 26, 2011

Uh oh!

vstinner commented Apr 26, 2011

Uh oh!

abalkin commented Apr 26, 2011

Uh oh!

abalkin commented Apr 26, 2011

Uh oh!

vstinner commented Apr 26, 2011

Uh oh!

vstinner commented May 1, 2011

Uh oh!

python-dev mannequin commented May 2, 2011

Uh oh!

python-dev mannequin commented May 2, 2011

Uh oh!

python-dev mannequin commented May 2, 2011

Uh oh!

vstinner commented May 2, 2011

Uh oh!