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'

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.

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.

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.

If %z works only in certain circumstances that behaviour should be documented wherever %z is referred to.

If concrete tzinfo subclass is added to datetime module (see issue5094), it will become feasible to meaningfully parse timezone information.

Attached patch includes issue 5094 patch.

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?

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.

With issue5094 patch now committed, I am replacing issue6641.diff with a new version that does not include issue5094.

Mark,

I am reassigning this to you for a commit review.

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.

Hmm. Hold on a sec;  I'm getting test failures...

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'

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.

LGTM.

Committed in r82053.

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.

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.

Replacing issue6641b.diff after fixing some spelling errors.  Thanks, Ezio.

Committed in r82073.

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.