Repository navigation
No way to generate or parse timezone as produced by datetime.isoformat() #69142
Description
| BPO | 24954 |
|---|---|
| Nosy | @tim-one, @warsaw, @jcea, @abalkin, @vstinner, @jwilk, @mcepl, @merwok, @bitdancer, @karlcow, @flying-sheep, @mihaic, @Fak3, @berkerpeksag, @vadmium, @ztane, @boxed, @jstasiak, @offby1, @deronnax, @pbryan, @pganssle, @sirex, @mariocj89, @sonots |
| Dependencies | |
| Files |
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:
assignee = 'https://github.com/abalkin'
closed_at = None
created_at = <Date 2015-08-28.22:34:41.660>
labels = ['extension-modules', 'easy', 'type-feature', '3.7']
title = 'No way to generate or parse timezone as produced by datetime.isoformat()'
updated_at = <Date 2018-07-05.19:25:05.940>
user = 'https://github.com/gvanrossum'bugs.python.org fields:
activity = <Date 2018-07-05.19:25:05.940>
actor = 'gvanrossum'
assignee = 'belopolsky'
closed = False
closed_date = None
closer = None
components = ['Extension Modules']
creation = <Date 2015-08-28.22:34:41.660>
creator = 'gvanrossum'
dependencies = ['31800']
files = ['40675', '40692']
hgrepos = ['319']
issue_num = 24954
keywords = ['patch', 'easy']
message_count = 24.0
messages = ['249305', '249815', '252284', '252294', '252364', '252366', '252449', '270530', '270531', '270543', '270573', '270575', '270579', '270826', '299213', '299237', '299239', '299241', '299333', '299339', '304596', '305015', '305016', '321108']
nosy_count = 36.0
nosy_names = ['tim.peters', 'barry', 'jcea', 'roysmith', 'belopolsky', 'nagle', 'vstinner', 'jwilk', 'mcepl', 'eric.araujo', 'Arfrever', 'r.david.murray', 'davydov', 'cvrebert', 'karlcow', 'SilentGhost', 'perey', 'flying sheep', 'mihaic', 'aymeric.augustin', 'Roman.Evstifeev', 'berker.peksag', 'martin.panter', 'piotr.dobrogost', 'kirpit', 'ztane', 'Anders.Hovm\xc3\xb6ller', 'jstasiak', 'Eric.Hanchrow', 'deronnax', 'pbryan', 'shanmbic', 'p-ganssle', 'sirex', 'mariocj89', 'sonots']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'commit review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue24954'
versions = ['Python 3.7']Metadata
Metadata
Assignees
Projects
- Status
Activity
gvanrossum commentedon Aug 28, 2015
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...
abalkin commentedon Sep 4, 2015
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.
shanmbic commentedon Oct 4, 2015
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
Thanks
vadmium commentedon Oct 5, 2015
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.
shanmbic commentedon Oct 5, 2015
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 .
I have rectified my code, corrected the indentations and have added cases , where it will also handle any strings of form '%:z' and '%::z' i.e. any character other than 'z' also raising exceptions for cases "%:" or "%::", where no character is specified (Invalid string).
In case , if we only go with '%:z' format specifier , I will remove the code for '%::z'.
P.S. I have filled the contributor agreement form. Thanks for the awesome help here. :)
abalkin commentedon Oct 5, 2015
I think it is very likely that bpo-5288 will result in at least seconds being allowed in UTC offsets in Python 3.6. I am assuming that much in my PEP-495 work in bpo-24773.
vadmium commentedon Oct 7, 2015
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.
abalkin commentedon Jul 16, 2016
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\>.
abalkin commentedon Jul 16, 2016
Sorry, the tracker messed up the URL: go to
https://github.com/abalkin/cpython.git
and select branch:bpo-24773-s3
14 remaining items
gvanrossum commentedon Oct 26, 2017
SGTM.
pganssle commentedon Jul 5, 2018
I believe this can be consolidated with bpo-15873 and closed, since that is finished and available in Python 3.7.
ThomasWaldmann commentedon Aug 13, 2022
Seems like there is still no way to have a custom format (like something including the suggested
%:z) that generates the tzoffset in the same way asdatetime.isoformat()would generate it:+HH:MM.Thus, see topic of this issue, this can't be closed yet.
ThomasWaldmann commentedon Aug 13, 2022
gvanrossum commentedon Aug 13, 2022
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?
ThomasWaldmann commentedon Aug 14, 2022
@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.
gh-69142: add %:z strftime format code (gh-95983)
gvanrossum commentedon Aug 28, 2022
Closed by gh-95983. Thanks again TW!