[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Change by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Paul Ganssle added the comment: I believe this can be consolidated with #15873 and closed, since that is finished and available in Python 3.7. -- nosy: +p-ganssle ___ Python tracker

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Guido van Rossum added the comment: SGTM. -- ___ Python tracker ___ ___ Python-bugs-list

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Alexander Belopolsky added the comment: I am going to merge PR 4015 submitted for issue 31800. That issue asks to make %z strptime format accept offsets with : separators. Given that a similar feature has been added to glibc several years ago, I don't see

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Mario Corchero added the comment: Wrote https://bugs.python.org/issue31800 without realising this issue was open (Thanks for bringing it up Martin Panter). issue31800 basically just adds the ability to parse NN:NN to the already existing python isoformat function when %z

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Change by Mario Corchero : -- nosy: +mariocj89 ___ Python tracker ___ ___

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Alexander Belopolsky added the comment: 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

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

John Nagle added the comment: As the original author of the predecessor bug report (issue 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,

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Guido van Rossum added the comment: Please do! I have no opinion on %::z but maybe you can find inspiration in the Zen of Python. :-) -- ___ Python tracker

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Alexander Belopolsky added the comment: This issue is waiting for the final decision on #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

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Guido van Rossum added the comment: Alexander, can you summarize the status of this issue? Maybe we can move forward for 3.7? -- ___ Python tracker ___

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Naotoshi Seo added the comment: Any progress here? I want `%:z` strftime. By the way, ruby strptime works as: ``` irb(main):008:0* Time.strptime('2015-01-01T01:01:01+09:00', '%Y-%m-%dT%H:%M:%S%z') => 2015-01-01 01:01:01 +0900 irb(main):009:0> Time.strptime('2015-01-01T01:01:01+0900',

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Changes by Mantas Zimnickas : -- nosy: +sirex ___ Python tracker ___ ___ Python-bugs-list

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Anders Hovmöller added the comment: > The `arrow` library depends on the supposed "strict" behaviour of strptime > that has never been guaranteed, which often results in very buggy behaviour > under some conditions. Well… the arrow library accepts all sorts of broken input and gives you a

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Alexander Belopolsky added the comment: 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

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Antti Haapala added the comment: Alexander: that is true, because they are *separate* conversion flags. However even the POSIX standard strptime has some leniency: '%m` and `%d` accept the numbers *without* leading zeroes. This actually also means that one cannot use `%Y%m%d` to detect an

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Alexander Belopolsky added the comment: "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 issue 15873), but setptime seems to be about specifying an exact format. For example,

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Antti Haapala added the comment: "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

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Alexander Belopolsky added the comment: Sorry, the tracker messed up the URL: go to https://github.com/abalkin/cpython.git and select branch:issue24773-s3 -- ___ Python tracker

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Alexander Belopolsky added the comment: Since this is closely related to issue 15873, I am merging the nosy lists. As far as I can tell, the patch just needs tests and a final decision on issue 5288. I don't think it is at all controversial, but we need to relax the offset restrictions before

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Martin Panter added the comment: Okay I am happy to be wrong about Python allowing seconds resolution. I notice that Issue 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

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

shanmbic added the comment: 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

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Martin Panter added the comment: 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

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Changes by Martin Panter : -- components: +Extension Modules -ctypes ___ Python tracker ___

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Changes by Alexander Belopolsky : -- assignee: -> belopolsky keywords: +easy ___ Python tracker ___

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Alexander Belopolsky added the comment: This request is similar to (if not a duplicate of) issue 15873. Gnu date uses the following extensions to %z instruction of strftime/strptime: %z +hhmm numeric timezone (e.g., -0400) %:z+hh:mm numeric timezone (e.g., -04:00)

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Changes by Alexander Belopolsky : -- stage: -> needs patch type: -> enhancement ___ Python tracker ___

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

New submission from Guido van Rossum: 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