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)

>>> datetime.strptime('1', '%Y')
ValueError: time data '1' does not match format '%Y'

FWIW, issue #1777412 added support for years < 1000 to Python 3.3 strftime.

I am not sure this can be fixed without distributing our own implementation of strftime.  See issue 3173.

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'

BTW, these discrepancies are already mentioned:
http://docs.python.org/dev/library/datetime.html#strftime-strptime-behavior

“The full set of format codes supported varies across platforms, because Python calls the platform C library’s strftime() function, and platform variations are common.”

We should had an asterisk to the "%Y" saying that the padding is not consistent across platforms.

Proposed patch to fix the issue in xmlrpc.client

New changeset 3f025427f02b by Florent Xicluna in branch 'default':
Fix regression due to changeset 2096158376e5 (issue #13305).
http://hg.python.org/cpython/rev/3f025427f02b

Le 01/11/2011 00:07, Roundup Robot a écrit :
>
> Roundup Robot<devnull@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

I don't like this hack. If there is a bug in time.strftime(), we need to 
fix time.strftime(), not xmlrpclib.

Is there a test for the hack?

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

Did your commit fix the issue or not?

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 ISO-8601 representations.

Now it is a documentation issue: add a comment to the "%Y" specifier saying that the padding is not applicable to all platforms and in such case the "%4Y" specifier should return the 4-digit value.

Since the changeset 55a3b563f0dbed04af317f632f7f3c0f6abe175b, test_strptime is failing on "AMD64 Gentoo Wide 3.x" buildbot:

======================================================================
FAIL: test_strptime (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/test/test_time.py", line 159, in test_strptime
    time.strptime(strf_output, format)
ValueError: time data 'LMT' does not match format '%Z'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/test/test_time.py", line 162, in test_strptime
    (format, strf_output))
AssertionError: conversion specifier '%Z' failed with 'LMT' input.

----------------------------------------------------------------------

http://www.python.org/dev/buildbot/all/builders/AMD64%20Gentoo%20Wide%203.x/builds/2661

other test_time related errors are followed with issue 13309, issue 13312 and issue 13313