PEP 321: Date/Time Parsing and Formatting

[Paul Moore]

"A.M. Kuchling" <amk at amk.ca> writes:

> On Mon, 17 Nov 2003 22:00:38 +0000, 
> 	Paul Moore <pf_moore at yahoo.co.uk> wrote:
>> I'd go for this option. Actually, I'd support including Gustavo's
>> dateutil module in the standard library. This PEP then involves adding
>> a number of additional (specialised) parsers to the dateutil.parser
>> subpackage.
>
> Actually I think the PEP mostly evaporates, especially if verbal dates
> aren't covered.  The common cases are then trivial with DateUtil, leaving
> only a few cases such as RFC-2822 times.

The PEP is pretty borderline, in any case. Not because the
functionality isn't useful, but because most of it exists somewhere
already. So the PEP is more of the form "now that we have datetime,
consolidating the parsing stuff would be good".

Specifically:

    def dt_strptime(s, fmt):
        tm = time.strptime(s, fmt)[:6]
        return datetime(*tm)

    def dt_rfc2822(s):
        tm = email.Utils.parsedate(s)[:6]
        return datetime(*tm)

This isn't to say that these are immediately obvious (it took me a
while to realise that using the * form of call saved a horribly long
and ugly constructor call)

If this is worth doing, I'd have to say that time.strptime, and
email.Utils.parsedate should get deprecated in favour of the "new
forms". And I'm not sure I can see that being acceptable.

I guess I'm -0 on the PEP as it stands. Incorporate it into a more
general "date/time utilities" module, and I'm +1.

Also, I'm -1 on adding anything to the datetime module itself (this
includes adding more classmethods to the types). The module is clean,
and lean as it stands. Bloating it (particularly under the banner of
"it's more OO to keep the functions as part of the classes") doesn't
appeal to me at all.

Paul.
-- 
This signature intentionally left blank