[Python-Dev] datetime issues
tim.one at comcast.net
Sun Sep 14 20:35:35 EDT 2003
> 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
> 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
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.
More information about the Python-Dev