[issue13305] datetime.strftime("%Y") not consistent for years < 1000

Jason R. Coombs added the comment: The tempora library implements a [portable strftime](https://tempora.readthedocs.io/en/latest/index.html#tempora.strftime). -- ___ Python tracker

[issue13305] datetime.strftime("%Y") not consistent for years < 1000

Chris Larson added the comment: Has there been any work/progress on this? Alternatively, what suggested work around/mitigations are suggested? -- nosy: +cklarson ___ Python tracker

[issue13305] datetime.strftime("%Y") not consistent for years < 1000

Fredrik Bengtsson added the comment: This also causes an issue when using stftime and strptime together on Linux (Ubuntu 20.04.1 LTS). When encoding a datetime using strftime and decoding with strptime using the same pattern an error is raised if year < 1000. Example: >>> pattern =

[issue13305] datetime.strftime("%Y") not consistent for years < 1000

STINNER Victor added the comment: > I'd like for Python to provide a portable implementation of strftime instead > of just documenting that the version isn't portable. If someone wants to do that, I suggest to first start with a project on PyPI. It sounds like a tricky project. Date, time,

[issue13305] datetime.strftime("%Y") not consistent for years < 1000

Jason R. Coombs added the comment: In issue39103, I filed a bug relating to this issue. I'd like for Python to provide a portable implementation of strftime instead of just documenting that the version isn't portable. Given that this ticket assigned to 'docs' suggests that a portable

[issue13305] datetime.strftime("%Y") not consistent for years < 1000

Change by Paul Ganssle : -- versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.6 ___ Python tracker ___ ___ Python-bugs-list

[issue13305] datetime.strftime("%Y") not consistent for years < 1000

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue13305] datetime.strftime("%Y") not consistent for years < 1000

Ned Deily added the comment: (See also msg307413 in duplicate Issue32195 for more discussion.) -- nosy: +ned.deily ___ Python tracker

[issue13305] datetime.strftime("%Y") not consistent for years < 1000

Roundup Robot added the comment: New changeset e54224e8d6a9 by Victor Stinner in branch 'default': Revert change 291d47954618 https://hg.python.org/cpython/rev/e54224e8d6a9 -- ___ Python tracker

[issue13305] datetime.strftime("%Y") not consistent for years < 1000

STINNER Victor added the comment: Elena's issue13305.diff: "Zero padding can be forced on some platforms by using e.g. ``%4Y``" Sorry, I still doesn't understand the change. %4Y doesn't work with strptime() and it only work with strftime() on very few platforms. Can you explain when %4Y

[issue13305] datetime.strftime("%Y") not consistent for years < 1000

STINNER Victor added the comment: >> About Elena Oat's patch issue13305.diff: I'm not sure that >> strftime("%4Y") works on all platforms > It doesn't, that's what the patch is trying to document. Oh. I confirm: %4Y gives "4Y" for any year on FreeBSD and Mac OS X, it raises

[issue13305] datetime.strftime("%Y") not consistent for years < 1000

Ezio Melotti added the comment: > About Elena Oat's patch issue13305.diff: I'm not sure that > strftime("%4Y") works on all platforms It doesn't, that's what the patch is trying to document. AFAICT it works on my Linux (but not on yours), it gives '4Y' on Mac, and raises an error on Windows.

[issue13305] datetime.strftime("%Y") not consistent for years < 1000

STINNER Victor added the comment: acucci's patch doc.patch suggests to use format "%4Y". Problem: I tried it on Linux, and it looks like it doesn't work. >>> datetime.datetime.strptime("1980", "%Y") datetime.datetime(1980, 1, 1, 0, 0) >>> datetime.datetime.strptime("1980", "%4Y") Traceback

[issue13305] datetime.strftime("%Y") not consistent for years < 1000

Roundup Robot added the comment: New changeset 291d47954618 by Victor Stinner in branch 'default': Always test datetime.strftime("%4Y") https://hg.python.org/cpython/rev/291d47954618 -- ___ Python tracker

[issue13305] datetime.strftime("%Y") not consistent for years < 1000

STINNER Victor added the comment: About Elena Oat's patch issue13305.diff: I'm not sure that strftime("%4Y") works on all platforms, so I enabled the test on strftime("%4Y"). I will check our buildbots. -- ___ Python tracker

[issue13305] datetime.strftime("%Y") not consistent for years < 1000

Elena Oat added the comment: I submitted a patch for documentation changes related to strftime "%Y" directive inconsistencies. I am not sure that specifying the OS is correct, because I haven't tested the inconsistencies on all Linux PCs, Windows versions or OS X. I still left them there

[issue13305] datetime.strftime("%Y") not consistent for years < 1000

Changes by Alessandro Cucci : Added file: http://bugs.python.org/file41476/doc.patch ___ Python tracker ___

[issue13305] datetime.strftime("%Y") not consistent for years < 1000

Martin Panter added the comment: At the bottom of it suggests that this four-digit field width specifier is not portable. Does that also hold for the datetime version? It seems like a bad idea to recommend an unportable workaround

[issue13305] datetime.strftime("%Y") not consistent for years < 1000

Ezio Melotti added the comment: > Also, using %4Y seems to consistently produce zero-padded values across > different platforms. Actually I was wrong. Based on some more testing I did on Linux and Windows 8 and the previous comments in this thread, it seems that, with 1 as year: * '%4Y' does

[issue13305] datetime.strftime("%Y") not consistent for years < 1000

Ezio Melotti added the comment: See msg146972 -- AFAIU the padding of %Y is inconsistent for years <1000 (e.g. 0042 vs 42), and this is not documented in the note (2) of https://docs.python.org/3/library/datetime.html#strftime-and-strptime-behavior Also, using %4Y seems to consistently produce

[issue13305] datetime.strftime("%Y") not consistent for years < 1000

Alexander Belopolsky added the comment: Can someone recap the status of this issue? It is classified as a documentation bug, but I don't see a clear statement of what is wrong with the documentation. -- versions: +Python 3.6 -Python 3.3 ___ Python

[issue13305] datetime.strftime(%Y) not consistent for years 1000

STINNER Victor victor.stin...@haypocalc.com added the comment: Did your commit fix the issue or not? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13305 ___

[issue13305] datetime.strftime(%Y) not consistent for years 1000

Florent Xicluna florent.xicl...@gmail.com added the comment: I understand that the issue is because the C standard does not specify the length of the string returned by '%Y'. The changeset 230f0956aaa3 adds a test to verify that either '%Y' or '%4Y' returns a 4-digits value usable to produce

[issue13305] datetime.strftime(%Y) not consistent for years 1000

STINNER Victor victor.stin...@haypocalc.com added the comment: Since the changeset 55a3b563f0dbed04af317f632f7f3c0f6abe175b, test_strptime is failing on AMD64 Gentoo Wide 3.x buildbot: == FAIL: test_strptime

[issue13305] datetime.strftime(%Y) not consistent for years 1000

Florent Xicluna florent.xicl...@gmail.com added the comment: other test_time related errors are followed with issue 13309, issue 13312 and issue 13313 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13305

[issue13305] datetime.strftime(%Y) not consistent for years 1000

STINNER Victor victor.stin...@haypocalc.com added the comment: Le 01/11/2011 00:07, Roundup Robot a écrit : Roundup Robotdevn...@psf.upfronthosting.co.za added the comment: New changeset 3f025427f02b by Florent Xicluna in branch 'default': Fix regression due to changeset 2096158376e5

[issue13305] datetime.strftime(%Y) not consistent for years 1000

Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 230f0956aaa3 by Florent Xicluna in branch 'default': Strengthen the tests for format '%Y', in relation with issue #13305. http://hg.python.org/cpython/rev/230f0956aaa3 --

[issue13305] datetime.strftime(%Y) not consistent for years 1000

New submission from Florent Xicluna florent.xicl...@gmail.com: See msg146725 on issue 13291. on linux datetime(1, 2, 10, 11, 41, 23).strftime(%Y) '1' on osx datetime(1, 2, 10, 11, 41, 23).strftime(%Y) '0001' datetime.strptime('0001', '%Y') datetime.datetime(1, 1, 1, 0, 0)

[issue13305] datetime.strftime(%Y) not consistent for years 1000

Florent Xicluna florent.xicl...@gmail.com added the comment: FWIW, issue #1777412 added support for years 1000 to Python 3.3 strftime. -- nosy: +belopolsky, haypo stage: test needed - needs patch versions: -Python 2.7, Python 3.2 ___ Python tracker

[issue13305] datetime.strftime(%Y) not consistent for years 1000

Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13305 ___ ___

[issue13305] datetime.strftime(%Y) not consistent for years 1000

Alexander Belopolsky alexander.belopol...@gmail.com added the comment: I am not sure this can be fixed without distributing our own implementation of strftime. See issue 3173. -- dependencies: +external strftime for Python? ___ Python tracker

[issue13305] datetime.strftime(%Y) not consistent for years 1000

Florent Xicluna florent.xicl...@gmail.com added the comment: There's many discrepancies between OS X and Linux about time formatting... OS X from datetime import datetime datetime(1900, 1, 1).strftime(%6Y) '6Y' Linux from datetime import datetime datetime(1900, 1, 1).strftime(%6Y) '001900'

[issue13305] datetime.strftime(%Y) not consistent for years 1000

Florent Xicluna florent.xicl...@gmail.com added the comment: Proposed patch to fix the issue in xmlrpc.client -- keywords: +patch Added file: http://bugs.python.org/file23577/issue13305_xmlrpc_patch.diff ___ Python tracker rep...@bugs.python.org

[issue13305] datetime.strftime(%Y) not consistent for years 1000

Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 3f025427f02b by Florent Xicluna in branch 'default': Fix regression due to changeset 2096158376e5 (issue #13305). http://hg.python.org/cpython/rev/3f025427f02b -- nosy: +python-dev