classification
Title: datetime.strftime with %Y no longer outputs leading zeros
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.6
process
Status: closed Resolution: duplicate
Dependencies: Superseder: datetime.strftime("%Y") not consistent for years < 1000
View: 13305
Assigned To: Nosy List: belopolsky, davechallis, ned.deily, ronaldoussoren, serhiy.storchaka
Priority: normal Keywords:

Created on 2017-12-01 14:39 by davechallis, last changed 2017-12-01 23:01 by ned.deily. This issue is now closed.

Messages (6)
msg307389 - (view) Author: Dave Challis (davechallis) Date: 2017-12-01 14:39
Tested in python 3.6.2:

    >>> import datetime
    >>> datetime.datetime.min.strftime('%Y')
    '1'

Expected output:

    '0001'

This means that strftime and strptime aren't necessarily symmetric, e.g.:

    >>> datetime.datetime.strptime(datetime.datetime.min.strftime('%Y'), '%Y')
    ValueError: time data '1' does not match format '%Y'
msg307398 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-12-01 17:46
In what version datetime.strftime with %Y did output leading zeros?
msg307401 - (view) Author: Dave Challis (davechallis) Date: 2017-12-01 19:05
My mistake, it appears to be related to the OS it's running on rather than the version (I just happened to test with different versions on different OSes).

On Mac OS X (with 3.6.2):

    >>> import datetime
    >>> datetime.datetime.min.strftime('%Y')
    '0001'

On Linux (with 3.6.2 again):

    >>> import datetime
    >>> datetime.datetime.min.strftime('%Y')
    '1
msg307413 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2017-12-01 22:40
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?
msg307415 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2017-12-01 22:56
Isn't this a duplicate of issue 13305?
msg307416 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2017-12-01 23:01
> Isn't this a duplicate of issue 13305?

Looks like it, thanks, though I think the analysis still applies.  Closing as duplicate.
History
Date User Action Args
2017-12-01 23:01:16ned.deilysetstatus: open -> closed
superseder: datetime.strftime("%Y") not consistent for years < 1000
messages: + msg307416

resolution: not a bug -> duplicate
stage: resolved
2017-12-01 22:56:43belopolskysetstatus: pending -> open

messages: + msg307415
2017-12-01 22:40:26ned.deilysetstatus: open -> pending
resolution: not a bug
messages: + msg307413
2017-12-01 19:31:50serhiy.storchakasetnosy: + ronaldoussoren, ned.deily
2017-12-01 19:05:42davechallissetmessages: + msg307401
2017-12-01 17:46:33serhiy.storchakasetnosy: + serhiy.storchaka, belopolsky
messages: + msg307398
2017-12-01 14:39:29davechalliscreate