[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.