Ned Deily <n...@python.org> added the comment: As documented in the Python Library Reference: "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. To see the full set of format codes supported on your platform, consult the strftime(3) documentation."
And this appears to be one of those differences, presumably another GNU libc vs BSD one, as I see the same behavior as macOS on the FreeBSD system I have available. The Open Group 2008 documentation for the strftime C interface discusses this problem a bit here (http://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html): "The %Y conversion specification to strftime() was frequently assumed to be a four-digit year, but the ISO C standard does not specify that %Y is restricted to any subset of allowed values from the tm_year field. Similarly, the %C conversion specification was assumed to be a two-digit field and the first part of the output from the %F conversion specification was assumed to be a four-digit field. With tm_year being a signed 32 or more-bit int and with many current implementations supporting 64-bit time_t types in one or more programming environments, these assumptions are clearly wrong. POSIX.1-2008 now allows the format specifications %0xC, %0xF, %0xG, and %0xY (where 'x' is a string of decimal digits used to specify printing and scanning of a string of x decimal digits) with leading zero fill characters. Allowing applications to set the field width enables them to agree on the number of digits to be printed and scanned in the ISO 8601:2000 standard expanded representation of a year (for %F, %G, and %Y ) or all but the last two digits of the year (for %C ). This is based on a feature in some versions of GNU libc's strftime(). The GNU version allows specifying space, zero, or no-fill characters in strftime() format strings, but does not allow any flags to be specified in strptime() format strings. These implementations also allow these flags to be specified for any numeric field. POSIX.1-2008 only requires the zero fill flag ( '0' ) and only requires that it be recognized when processing %C, %F, %G, and %Y specifications when a minimum field width is also specified. The '0' flag is the only flag needed to produce and scan the ISO 8601:2000 standard year fields using the extended format forms. POSIX.1-2008 also allows applications to specify the same flag and field width specifiers to be used in both strftime() and strptime() format strings for symmetry. Systems may provide other flag characters and may accept flags in conjunction with conversion specifiers other than %C, %F, %G, and %Y; but portable applications cannot depend on such extensions." Experimenting a bit, it seems that the current Linux glibc implementation supports the %0xY extension while the current macOS (and other BSD?) do not. Python 3.6.3 (default, Oct 3 2017, 21:16:13) [GCC 7.2.0] on linux >>> datetime.datetime.min.strftime('%Y') '1' >>> datetime.datetime.min.strftime('%02Y') '01' >>> datetime.datetime.min.strftime('%04Y') '0001' Python 3.6.3 (v3.6.3:2c5fed86e0, Oct 3 2017, 00:32:08) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin >>> datetime.datetime.min.strftime('%Y') '0001' >>> datetime.datetime.min.strftime('%02Y') '2Y' >>> datetime.datetime.min.strftime('%04Y') '4Y' So I'm afraid there's not much we can do about that without changing Python's policy about using the platform's native implementations of date and time functions. Alexander, do you agree? ---------- resolution: -> not a bug status: open -> pending _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32195> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
