Matching +-HH:MM in strptime
There is a new issue about the %z directive in strptime on the issue tracker: https://bugs.python.org/issue31800 (linked to a few related issues), and a linked PR expanding the definition of %z to match HH:MM: https://github.com/python/cpython/pull/4015 I think either adding a %:z directive or expanding the definition of %z would be pretty important, and I think there's a good case to be made for either one. To summarize the arguments for people on the mailing list: The argument for expanding the definition of %z that I find strongest is that according to the linux man pages ( http://man7.org/linux/man-pages/man3/strptime.3.html ), while %z generates +-HHMM in strftime, strptime is supposed to match "An RFC-822/ISO 8601 standard timezone specification",and ISO 8601 uses +-HH:MM, so if we're following those linux pages, we should be accepting the version with the colon. The argument that I find most compelling for adding a %:z directive are: 1. maintains the symmetry between strftime and strptime 2. allows users to be stricter about their datetime format 3. has precedent in that GNU's `date` command accepts %z, %:z and %::z formats Can we establish some consensus on which should be done so that it can be implemented? Best, Paul
On Thu, Oct 19, 2017, at 10:06, Paul G wrote:
The argument for expanding the definition of %z that I find strongest is that according to the linux man pages ( http://man7.org/linux/man-pages/man3/strptime.3.html ), while %z generates +-HHMM in strftime, strptime is supposed to match "An RFC-822/ISO 8601 standard timezone specification",and ISO 8601 uses +-HH:MM, so if we're following those linux pages, we should be accepting the version with the colon.
For whatever it's worth glibc strptime on linux does *not* in fact accept +HH:MM, and if it is passed, it silently interprets, say, -05:30 as -05 (and :30 remains in the string for subsequent directives to consume). Testing with an offset with zero minutes at the end of the string does not account for this, which may be why some people in the bug comments reported that it did support it.
The argument that I find most compelling for adding a %:z directive are:
1. maintains the symmetry between strftime and strptime 2. allows users to be stricter about their datetime format 3. has precedent in that GNU's `date` command accepts %z, %:z and %::z formats
Just to be clear, date accepts them on input through date -d (which does not use strptime or posix getdate, but its own internal parse_datetime function)
Can we establish some consensus on which should be done so that it can be implemented?
I do think it should be done, but if so it may be reasonable to talk about implementing a portable version of time.strptime that will also implement this feature.
https://github.com/orent/cpython/tree/strptime_extensions
%:z - matches +HH:MM
%?:z - optional %:z
%.f - equivalent to .%f
%?.f - optional %.f
%?t - matches ' ' or 'T'
What they all have in common is that together they make it possible to
write a strptime format that matches all possible output variations of
datetime.__str__/ datetime.isoformat.
The time zone not only supports the : separator but also allows making the
entire component optional, as isoformat() will add it only for aware
datetime objects. The seconds fraction is dropped from the default string
representation if the datetime represents a whole second. Since it is
dropped along with the decimal dot, I first made "%.f" that includes the
dot and then created the optional variant. Finally, "%?t" can be used to
accept a timestamp with either of the separators defined in iso8601.
It is quite absurd that datetime cannot parse its own string
representation. Using these extensions an .isoparse() method may be added
that calls strptime('%Y-%m-%d%?t%H:%M:%S%?.f%?:z') and supports full
round-tripping of all possible datetime values that do not not use a custom
tzinfo.
Oren
On Thu, 19 Oct 2017 at 17:06, Paul G
There is a new issue about the %z directive in strptime on the issue
tracker: https://bugs.python.org/issue31800 (linked to a few related issues), and a linked PR expanding the definition of %z to match HH:MM: https://github.com/python/cpython/pull/4015
I think either adding a %:z directive or expanding the definition of %z
would be pretty important, and I think there's a good case to be made for either one. To summarize the arguments for people on the mailing list:
The argument for expanding the definition of %z that I find strongest is
that according to the linux man pages ( http://man7.org/linux/man-pages/man3/strptime.3.html ), while %z generates +-HHMM in strftime, strptime is supposed to match "An RFC-822/ISO 8601 standard timezone specification",and ISO 8601 uses +-HH:MM, so if we're following those linux pages, we should be accepting the version with the colon.
The argument that I find most compelling for adding a %:z directive are:
1. maintains the symmetry between strftime and strptime 2. allows users to be stricter about their datetime format 3. has precedent in that GNU's `date` command accepts %z, %:z and
%::z formats
Can we establish some consensus on which should be done so that it can be
implemented?
Best,
Paul
_______________________________________________ Datetime-SIG mailing list Datetime-SIG@python.org https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list:
participants (3)
-
Oren Tirosh -
Paul G -
Random832