Repository navigation
datetime.strptime doesn't support %z format ? #50890
Description
| BPO | 6641 |
|---|---|
| Nosy | @brettcannon, @mdickinson, @abalkin, @merwok |
| 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 = <Date 2010-06-18.18:49:24.333>
created_at = <Date 2009-08-04.14:04:36.567>
labels = ['type-feature']
title = "datetime.strptime doesn't support %z format ?"
updated_at = <Date 2010-06-19.04:36:22.073>
user = 'https://bugs.python.org/eka'bugs.python.org fields:
activity = <Date 2010-06-19.04:36:22.073>
actor = 'eric.araujo'
assignee = 'belopolsky'
closed = True
closed_date = <Date 2010-06-18.18:49:24.333>
closer = 'belopolsky'
components = ['None']
creation = <Date 2009-08-04.14:04:36.567>
creator = 'eka'
dependencies = ['5094']
files = ['17681', '17699', '17710']
hgrepos = []
issue_num = 6641
keywords = ['patch']
message_count = 22.0
messages = ['91256', '91282', '91763', '91780', '106434', '106473', '107329', '107549', '107555', '107797', '107902', '108032', '108033', '108034', '108038', '108039', '108041', '108115', '108116', '108117', '108127', '108166']
nosy_count = 8.0
nosy_names = ['brett.cannon', 'mark.dickinson', 'belopolsky', 'eric.araujo', 'eka', 'dmhouse', 'abrown', 'dudologist']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue6641'
versions = ['Python 3.2']
Activity
eka commentedon Aug 4, 2009
When trying to use datetime.strptime %z directive got an unexpected error.
dmhouse commentedon Aug 4, 2009
From the documentation from time.strptime() (which acts the same as
datetime.strptime()):
"Only the directives specified in the documentation [of time.strftime()]
are supported. Because strftime() is implemented per platform it can
sometimes offer more directives than those listed. But strptime() is
independent of any platform and thus does not necessarily support all
directives available that are not documented as supported."
So I think invalid.
abrown commentedon Aug 20, 2009
I think this bug is just a doc bug. If you check
http://docs.python.org/library/datetime.html?highlight=strptime#strftime-behavior
and
http://docs.python.org/library/time.html?highlight=strptime#time.strptime
You can see that the first link lists %z as a valid modifier, while in
the second link (in footnote 1) it is mentioned as deprecated.
dmhouse commentedon Aug 20, 2009
Yes and no.
Firstly, %z isn't listed as deprecated in the documentation of the time
module's strftime -- although %Z is (note differing case).
Secondly, I still think the bug is invalid, because the documentation of
datetime.datetime.strptime says it behaves like time.strptime, whose
documentation says "only the directives specified in the documentation
[of strftime()] are supported". Since we're in the time module, that
reference to strftime() means time.strftime(), which doesn't list %z as
a directive.
Finally, there *is* a confusing docs issue, however: the "strftime()
behaviour" section in the datetime module documentation lists %z as a
valid directive, whereas it's not listed in time.strftime. Although
these functions have in theory nothing to do with one another, you would
in practice expect them to support the same directives.
Since in fact the footnote in the documentation of time.strftime() says
%z isn't supported by all ANSI C platforms (despite apparently being
required by the standard), I suggest that %z be removed from the list of
allowed modifiers in the "strftime() behaviour" section in the datetime
module documentation.
dudologist commentedon May 25, 2010
If %z works only in certain circumstances that behaviour should be documented wherever %z is referred to.
abalkin commentedon May 25, 2010
If concrete tzinfo subclass is added to datetime module (see bpo-5094), it will become feasible to meaningfully parse timezone information.
abalkin commentedon Jun 8, 2010
Attached patch includes bpo-5094 patch.
mdickinson commentedon Jun 11, 2010
It's a little awkward to review this patch independently of the bpo-5094 patch. Can we work on bpo-5094 first, and then come back to this one?
abalkin commentedon Jun 11, 2010
On Fri, Jun 11, 2010 at 10:43 AM, Mark Dickinson <report@bugs.python.org> wrote:
..
Sure. Unfortunately, I think I fixed a few timezone doc warts here
and did not update 5094. I will fix that.
abalkin commentedon Jun 14, 2010
With bpo-5094 patch now committed, I am replacing bpo-6641.diff with a new version that does not include bpo-5094.
[-]strptime doesn't support %z format ?[/-][+]datetime.strptime doesn't support %z format ?[/+]5 remaining items
mdickinson commentedon Jun 17, 2010
Hmm. Hold on a sec; I'm getting test failures...
mdickinson commentedon Jun 17, 2010
In test_datetime:
======================================================================
ERROR: test_strptime (main.TestDateTime)
----------------------------------------------------------------------
======================================================================
ERROR: test_strptime (main.TestDateTimeTZ)
----------------------------------------------------------------------
abalkin commentedon Jun 17, 2010
issue6641a.diff fixes the nits that Mark found and makes the tests robust with respect to change of timezones. Tested with all timezones avalilable on OSX including TZ="Eire". (Ever heard of Ouagadougou?)
Parsing RFC 3339's HH:MM format is a separate issue. I am +1 on either adding %:z specifier or simply allow HH:MM for %z.
mdickinson commentedon Jun 17, 2010
LGTM.
abalkin commentedon Jun 17, 2010
Committed in r82053.
abalkin commentedon Jun 18, 2010
Reopening because the patch introduced a regression with respect to datetime subclasses:
a DT instance expected. Need tests covering subclasses.
abalkin commentedon Jun 18, 2010
Attaching issue6641b.diff that fixes subclassing issue. Added tests for datetime subclass only to keep the patch focused. Adding tests for datetime and time subclasses will be natural in bpo-1100942.
abalkin commentedon Jun 18, 2010
Replacing issue6641b.diff after fixing some spelling errors. Thanks, Ezio.
abalkin commentedon Jun 18, 2010
Committed in r82073.
merwok commentedon Jun 19, 2010
PEP-8 says: “If your public attribute name collides with a reserved keyword, append a single trailing underscore to your attribute name. This is preferable to an abbreviation or corrupted spelling.” e.g. “class_” is used for an HTML class. “(However, notwithstanding this rule, 'cls' is the preferred spelling for any variable or argument which is known to be a class, especially the first argument to a class method.)” I’d like this recommendation to be followed, even if it’s in an internal function.