[Python-Dev] datetime issues

[Tim Peters]

[Gustavo Niemeyer]
> Is there any reason for not having a single keyword parameter for
> every function accepting a tzinfo instance?

Just the lack of anyone pointing it out in the module's 18-month review
process <wink>.

> I've noticed that some require 'tz', and others 'tzinfo'. Is it too
> late to fix that?

Of course, although it's not too late to add synonyms.  It appears that the
functions "with a lot of arguments" use tzinfo, and those with only one or
two arguments tz now.  I doubt anyone would bother to use the tz keyword-arg
name for a few-argument function (now(), fromtimestamp(), astimezone()), so
I'd rather that those few grow a tzinfo synonym.  tz can be deprecated too,
if you're bold.

> Also, is there any further work going on to improve the datetime
> module?

Not that I'm aware of.  I'm not working on it anymore (other than keeping my
out for bug reports, of which there have been blessedly few).

> I'm not suggesting we should mirror mx.DateTime functionalities, but
> two features I miss from mx.DateTime is the DateFrom(), which does its
> best to parse a given string, and the RelativeDateTime() functionality.
>
> This has probably been raised in the past, so if that's the case, I'm
> sorry. Marc-Andre, what's your opinion about reusing code from
> mx.DateTime into datetime?
>
> Anyway, reusing code or not, I'll probably put sometime on it in the
> future, if this looks interesting to everyone (after I finish my
> current python pendencies, like SRE's recursivity removal).

If Guido wanted to stay out of the relatively clear <snort> time zone
business, I can imagine his interest in trying to guess how to parse date
and time strings.  Apart from Brett's strptime(), I believe the email module
has some useful string->datetime code.  It may be good to fold such stuff in
this area as Python already supports into datetime somehow.