DateTimeParser fails silently for certain inputs

[Jonathan Knowles]

DateTimeParser fails silently for several classes of date with the hyphen ("-") as a separator character:

* M-DD-YYYY
* MM-D-YYYY
* YYYY-M-D
* YYYY-M-DD
* YYYY-MM-D

For dates matching any of the above patterns, DateTimeParser ignores the month and day components and always returns 1 for the month and day values. For example, the string '2-13-2001' is interpreted as January 1st 2001.

Seen in version 38178 of zope.app.datetimeutils.

[Jonathan Knowles (jsk)]

A summary of the failing patterns with examples.

[Eleanor Berger (intellectronica)]

the mxDateTime library does a really good job at parsing lots of different date/time formats. maybe we should consider using it for parsing.

http://www.egenix.com/products/python/mxBase/mxDateTime/

[Andreas Jung (ajung)]

"""

the mxDateTime library does a really good job at parsing lots of different date/time formats. maybe we should consider using it for parsing.

http://www.egenix.com/products/python/mxBase/mxDateTime/
"""

mxDateTime will never be used within Zope.

[Tres Seaver (tseaver)]

The DateTimeParser class moved out of zope.app.datetime into zope.datetime as part of dependency reduction.

[Tres Seaver (tseaver)]

lp:~tseaver/zope.datetime/lp_139360 shows all 1638 tests from Jonathan Knowles suite passing against the version of 'parse' now in zope.datetime.(code unchanged since the 3.4.0 release). Recommended fix for application code is to import the 'parse' function and relateed stuff from zope.datetime, rather than the (now abandoned) zope.app.datetimeutils.

[Curtis Hovey (sinzui)]

lp.services.fields.FormattableDate supports the correct behaviour. The interfaces can be updated to use the better class. close this bug.

[Robert Collins (lifeless)]

Marked as wontfix in the lp components as per your comment.