-
-
Notifications
You must be signed in to change notification settings - Fork 32k
No way to generate or parse timezone as produced by datetime.isoformat() #69142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The datetime isoformat() function for an aware datetime appends the timezone in the form +HH:MM or -HH:MM. But the %z format produces (strftime) or parses (strptime) either +HHMM or -HHMM. I looked it up on Wikipedia, and the ISO 8601 standard indeed uses the colon. It would be nice if there was a new format character that could produce or parse the colon... |
This request is similar to (if not a duplicate of) bpo-15873. Gnu date uses the following extensions to %z instruction of strftime/strptime:
I think it is reasonable to add those to python. |
I modified the "format_utcoffset" function in "_datetimemodule.c", to accept one more parameter "secondsrequired" . It is a boolean variable (PyObject) , which when set to true, the function will return the offset formatted as "+HH:MM:SS" or "-HH:MM:SS". I also modified the "wrap_strftime" function to also accept the strings "%:z" and "%::z" as format specifiers. This is my first contribution to python , so my approach of modifying a function's default parameters might not be correct. Any help is appreciated |
I added some comments on Rietveld. I guess the documentation should get notices and What’s New entries saying it is new in 3.6. Test cases would be good, including negative ones to check error handling is sensible if the Z is missing. Also shanmbic, perhaps look at signing the contributor agreement <https://www.python.org/psf/contrib/\> if you haven’t already. Adding to the list of format codes means that the statement at the top of the list about them all being required by C89 will need fixing. For parsing, perhaps the existing %z code could be extended to accept colons, without needing to specify a new %:z code. Although if %:z is added for formatting, it should also be supported for parsing. I am not convinced that it is worth adding %::z or %:::z to Python. The documentation of tzinfo.utcoffset() says it returns the offset “in minutes”, hinting that sub-minute offsets are not supported. RFC 3339 acknowledges that sub-minute offsets exist in history, but AFAIK neither RFC 3339 nor ISO 8601 support them. So I think it is too specialized to build %::z into Python. And I don’t imagine the %:::z necessary precision version would be used much either. |
Yeah , I agree that including '%:::z' might not be necessary at all . Including '%:z' and '%::z' format specifiers will give an upper edge to Python. Although , if not going with '%::z' or seconds offset, for now only '%:z' can be a valuable addition . |
Okay I am happy to be wrong about Python allowing seconds resolution. I notice that bpo-12006 was committed, which adds a second table of Python-only codes for ISO 8601 values. The proposed entries here could be incorporated into that table, and the text above it modified to suit. That would solve my C89 library problem. |
Since this is closely related to bpo-15873, I am merging the nosy lists. As far as I can tell, the patch just needs tests and a final decision on bpo-5288. I don't think it is at all controversial, but we need to relax the offset restrictions before ::z code can go in. shanmbic, you can use my PEP-495 branch to test. See <https://github.com/abalkin/cpython.git#bpo-24773-s3\>. |
Sorry, the tracker messed up the URL: go to https://github.com/abalkin/cpython.git and select branch:bpo-24773-s3 |
"Be conservative in what you do, be liberal in what you accept from others" they say. Also Z as a timezone designator is also widely used in iso 8601 timestamps. I believe the effort should be made to *parse* *any/all* of the ISO 8601 supported time-zone codes with one conversion, the list is not that long, just 'Z', HH, HH:MM, HHMM, longest match. Literal 'Z' really does not need to be supported for *output* at all, but for input, please. Otherwise this will still go down the road of iso8601 library, which just tries to support all the YYmmddTHHMMSS.FFFFFFzzzz variants. It uses regular expressions to parse the dates as it is faster than trying N different formats with |
"Be conservative in what you do, be liberal in what you accept from others" I would agree to this approach with respect to a proposed fromisoformat() method (see bpo-15873), but setptime seems to be about specifying an exact format. For example, "%Y%m%d" will not accept "2016-07-16". |
Alexander: that is true, because they are *separate* conversion flags. However even the POSIX standard strptime has some leniency: '%m >>> datetime.datetime.strptime('111122', '%Y%m%d')
datetime.datetime(1111, 2, 2, 0, 0) The ---- (Also, it must be noted that GNU date program doesn't use these formats to *parse* dates, and POSIX strptime in *C* library outright ignores any timezone information) |
Antti, while I see some convenience in making %z parsing promiscuous, there is clear utility in adding %:z to strftime. If we do that, not allowing the same for parsing will be odd. Let's start with that. A case for a promiscuous %z can be made later. On a separate issue, note that datetime.isoformat() has recently grown a timespec option. See bpo-19475. I wonder if it would make sense to add a tzspec option to control the way timezone is formatted. |
Well… the arrow library accepts all sorts of broken input and gives you a date back. I think they even think that’s a feature and not a bug so no use in trying to help people who are adamant that they don’t want to be helped :/ |
Any progress here? I want By the way, ruby strptime works as:
|
Alexander, can you summarize the status of this issue? Maybe we can move forward for 3.7? |
This issue is waiting for the final decision on bpo-5288. If sub-minute offsets support is accepted, I still don't think we need %::z because %:z can simply add non-zero :seconds as needed. There are also some review comments on the latest patch that have not been addressed. Overall this is an easy issue and it would be quite doable to get it resolved for 3.7. |
Please do! I have no opinion on %::z but maybe you can find inspiration in the Zen of Python. :-) |
As the original author of the predecessor bug report (bpo-15873) in 2012, I would suggest that there's too much bikeshedding here. I filed this bug because there was no usable ISO8601 date parser available. PyPi contained four slightly different buggy ones, and three more versions were found later. I suggested following RFC3339, "Date and Time on the Internet: Timestamps", section 5.6, which specifies a clear subset of ISO8601. Five years later, I suggest just going with that. Fancier variations belong in non-standard libraries. Date parsing should not be platform-dependent. Using an available C library was convenient, but not portable. Let's get this done. |
John, An RFC3339 parser is beyond the scope of this issue which is limited to adding str[fp]time code(s) to produce and consume RFC3339-formatted timezones. We can still have fromisoformat() constructor implemented in 3.7, but someone needs to address the issues raised at bpo-15873. |
Wrote https://bugs.python.org/issue31800 without realising this issue was open (Thanks for bringing it up Martin Panter). bpo-31800 basically just adds the ability to parse NN:NN to the already existing python isoformat function when %z is specified. As available as well in linux strptime: http://man7.org/linux/man-pages/man3/strptime.3.html I'd really like to see a way to parse isoformatted dates and this is the only thing in the middle. Happy to continue with the other issue/PR or help out here if needed. Thanks! ^^ |
SGTM. |
I believe this can be consolidated with bpo-15873 and closed, since that is finished and available in Python 3.7. |
Seems like there is still no way to have a custom format (like something including the suggested Thus, see topic of this issue, this can't be closed yet. |
|
Indeed. There are some old patches attached to this diff. Would you like to clean one of those up and submit it as a PR? |
datetime.isoformat generates the tzoffset with colons, but there was no format code to make strftime output the same format. for simplicity and consistency the %:z formatting behaves mostly as %z, with the exception of adding colons. this includes the dynamic behaviour of adding seconds and microseconds only when needed (when not 0). this fixes the still open "generate" part of this issue: python#69142
@gvanrossum thanks for pointing me to the patches. I had a look at them, but then decided to implement in a slightly different and easier way. PR coming soon. |
datetime.isoformat generates the tzoffset with colons, but there was no format code to make strftime output the same format. for simplicity and consistency the %:z formatting behaves mostly as %z, with the exception of adding colons. this includes the dynamic behaviour of adding seconds and microseconds only when needed (when not 0). this fixes the still open "generate" part of this issue: python#69142
datetime.isoformat generates the tzoffset with colons, but there was no format code to make strftime output the same format. for simplicity and consistency the %:z formatting behaves mostly as %z, with the exception of adding colons. this includes the dynamic behaviour of adding seconds and microseconds only when needed (when not 0). this fixes the still open "generate" part of this issue: #69142 Co-authored-by: Kumar Aditya <[email protected]>
Closed by gh-95983. Thanks again TW! |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: