classification
Title: datetime.strptime doesn't support %z format ?
Type: enhancement Stage: resolved
Components: None Versions: Python 3.2
process
Status: closed Resolution: accepted
Dependencies: 5094 Superseder:
Assigned To: belopolsky Nosy List: abrown, belopolsky, brett.cannon, dmhouse, dudologist, eka, eric.araujo, mark.dickinson
Priority: normal Keywords: patch

Created on 2009-08-04 14:04 by eka, last changed 2010-06-19 04:36 by eric.araujo. This issue is now closed.

Files
File name Uploaded Description Edit
issue6641.diff belopolsky, 2010-06-16 02:20
issue6641a.diff belopolsky, 2010-06-17 17:53
issue6641b.diff belopolsky, 2010-06-18 17:09
Messages (22)
msg91256 - (view) Author: Esteban Feldman (eka) Date: 2009-08-04 14:04
When trying to use datetime.strptime %z directive got an unexpected error.

>>> from datetime import datetime
>>> 
>>> fecha = u'Sun Aug 02 19:01:25 +0000 2009'
>>> datetime.strptime(fecha, '%a %b %d %H:%M:%S %z %Y')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/_strptime.py", line 317, in _strptime
    (bad_directive, format))
ValueError: 'z' is a bad directive in format '%a %b %d %H:%M:%S %z %Y'
msg91282 - (view) Author: David House (dmhouse) Date: 2009-08-04 23:03
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.
msg91763 - (view) Author: Andrew Brown (abrown) Date: 2009-08-20 09:03
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.
msg91780 - (view) Author: David House (dmhouse) Date: 2009-08-20 16:39
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.
msg106434 - (view) Author: dudologist (dudologist) Date: 2010-05-25 13:22
If %z works only in certain circumstances that behaviour should be documented wherever %z is referred to.
msg106473 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-05-25 20:37
If concrete tzinfo subclass is added to datetime module (see issue5094), it will become feasible to meaningfully parse timezone information.
msg107329 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-06-08 16:40
Attached patch includes issue 5094 patch.
msg107549 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-06-11 14:43
It's a little awkward to review this patch independently of the issue 5094 patch.  Can we work on issue 5094 first, and then come back to this one?
msg107555 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-06-11 15:27
On Fri, Jun 11, 2010 at 10:43 AM, Mark Dickinson <report@bugs.python.org> wrote:
..
> It's a little awkward to review this patch independently of the issue 5094 patch.
>  Can we work on issue 5094 first, and then come back to this one?

Sure.  Unfortunately, I think I fixed a few timezone doc warts here
and did not update 5094.  I will fix that.
msg107797 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-06-14 16:09
With issue5094 patch now committed, I am replacing issue6641.diff with a new version that does not include issue5094.
msg107902 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-06-16 02:22
Mark,

I am reassigning this to you for a commit review.
msg108032 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-06-17 16:40
Doc nit: "When ``%z`` directive" -> "When the ``%z`` directive"

The _strptime._strptime docstring is inaccurate:  it claim to return a time struct, but actually returns tuple, int;  please could you also add docstrings for _strptime_time and _strptime_datetime?

Spacing in datetimemodule.c:  "if( module == NULL)" -> "if (module == NULL)".  Also, is there any particular reason for initializing 'result' to NULL?  (Or even for using result at all;  you could just do "return PyObject_CallMethod(... ").

I'm mildly distressed by the inability of strptime to parse UTC offsets in the +HH:MM form that str(timezone) produces, but I'm not sure what the solution to that is.

Otherwise, this all looks good to my non-expert eye.
msg108033 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-06-17 16:43
Hmm. Hold on a sec;  I'm getting test failures...
msg108034 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-06-17 16:44
In test_datetime:


======================================================================
ERROR: test_strptime (__main__.TestDateTime)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_datetime.py", line 1741, in test_strptime
    dt = strptime("-0500 EST", "%z %Z")
  File "/Users/dickinsm/python/svn/py3k/Lib/_strptime.py", line 483, in _strptime_datetime
    tt, fraction = _strptime(data_string, format)
  File "/Users/dickinsm/python/svn/py3k/Lib/_strptime.py", line 336, in _strptime
    (data_string, format))
ValueError: time data '-0500 EST' does not match format '%z %Z'

======================================================================
ERROR: test_strptime (__main__.TestDateTimeTZ)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_datetime.py", line 1741, in test_strptime
    dt = strptime("-0500 EST", "%z %Z")
  File "/Users/dickinsm/python/svn/py3k/Lib/_strptime.py", line 483, in _strptime_datetime
    tt, fraction = _strptime(data_string, format)
  File "/Users/dickinsm/python/svn/py3k/Lib/_strptime.py", line 336, in _strptime
    (data_string, format))
ValueError: time data '-0500 EST' does not match format '%z %Z'
msg108038 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-06-17 17:53
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.
msg108039 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-06-17 18:00
LGTM.
msg108041 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-06-17 18:32
Committed in r82053.
msg108115 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-06-18 15:43
Reopening because the patch introduced a regression with respect to datetime subclasses:


>>> class DT(datetime): pass
... 
>>> DT.strptime('', '')
datetime.datetime(1900, 1, 1, 0, 0)


a DT instance expected.  Need tests covering subclasses.
msg108116 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-06-18 16:10
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 issue 1100942.
msg108117 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-06-18 17:06
Replacing issue6641b.diff after fixing some spelling errors.  Thanks, Ezio.
msg108127 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-06-18 18:49
Committed in r82073.
msg108166 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-06-19 04:36
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.
History
Date User Action Args
2010-10-14 17:54:47belopolskylinkissue4086 superseder
2010-06-19 04:36:22eric.araujosetmessages: + msg108166
2010-06-18 18:49:24belopolskysetstatus: open -> closed

messages: + msg108127
stage: test needed -> resolved
2010-06-18 17:09:13belopolskysetfiles: - issue6641b.diff
2010-06-18 17:09:07belopolskysetfiles: + issue6641b.diff
2010-06-18 17:06:33belopolskysetfiles: - issue6641b.diff
2010-06-18 17:06:20belopolskysetfiles: + issue6641b.diff

messages: + msg108117
2010-06-18 16:10:18belopolskysetfiles: + issue6641b.diff

messages: + msg108116
2010-06-18 15:43:37belopolskysetstatus: closed -> open

messages: + msg108115
stage: resolved -> test needed
2010-06-17 18:33:17belopolskysetstatus: open -> closed
stage: commit review -> resolved
2010-06-17 18:32:47belopolskysetmessages: + msg108041
2010-06-17 18:00:29mark.dickinsonsetmessages: + msg108039
2010-06-17 17:53:50belopolskysetfiles: + issue6641a.diff
resolution: accepted
messages: + msg108038
2010-06-17 16:44:56mark.dickinsonsetmessages: + msg108034
2010-06-17 16:43:52mark.dickinsonsetmessages: + msg108033
2010-06-17 16:40:48mark.dickinsonsetassignee: mark.dickinson -> belopolsky
messages: + msg108032
2010-06-16 02:22:11belopolskysetassignee: belopolsky -> mark.dickinson
messages: + msg107902
2010-06-16 02:21:11belopolskysetfiles: - issue6641.diff
2010-06-16 02:21:03belopolskysetfiles: + issue6641.diff
2010-06-14 16:09:27belopolskysetfiles: - issue6641.diff
2010-06-14 16:09:18belopolskysetfiles: + issue6641.diff

messages: + msg107797
title: strptime doesn't support %z format ? -> datetime.strptime doesn't support %z format ?
2010-06-11 15:27:15belopolskysetmessages: + msg107555
2010-06-11 14:43:31mark.dickinsonsetmessages: + msg107549
2010-06-08 16:40:27belopolskysetfiles: + issue6641.diff

nosy: + mark.dickinson
messages: + msg107329

keywords: + patch
stage: test needed -> commit review
2010-06-08 14:15:29belopolskysetdependencies: + datetime lacks concrete tzinfo implementation for UTC
type: behavior -> enhancement
stage: test needed
versions: + Python 3.2, - Python 2.6
2010-06-01 18:56:06eric.araujosetnosy: + eric.araujo
2010-05-25 21:20:30brett.cannonsetnosy: + brett.cannon
2010-05-25 20:37:18belopolskysetassignee: belopolsky
messages: + msg106473
2010-05-25 17:20:46r.david.murraysetnosy: + belopolsky
2010-05-25 13:22:54dudologistsetnosy: + dudologist
messages: + msg106434
2009-08-20 16:39:34dmhousesetmessages: + msg91780
2009-08-20 09:03:24abrownsetnosy: + abrown
messages: + msg91763
2009-08-04 23:03:34dmhousesetnosy: + dmhouse
messages: + msg91282
2009-08-04 14:04:36ekacreate