[Python-Dev] Interop between datetime and mxDateTime

[Guido van Rossum]

> guido wrote:
> 
> > There was a proposal long ago that all datetime-like objects should
> > implement a timetuple() method.  Perhaps we should revive that?
> > datetime does implement this.
> 
> the last revision of the "time type" proposal seems to suggest that all
> time types should implement the following interface:
> 
>     tm = timeobject.timetuple()

This is specified in the proposal as returning local time if the
timeobject knows about timezones.  Unfortunately, the datetime module
has timezone support built in, but in such a way that no knowledge of
actual timezones is built into it.  In particular, the datetime module
is agnostic of the local timezone rules and regulations.  We currently
support timetuple() but it always returns the "naive time" represented
by a datetime object (stripping the timezone info rather converting to
local time).  Is this a problem?  If we have to convert to local time
using the facilities of the time module, timetuple() will only work
for dates supported by the time module (roughly 1970-2038 on most
systems), and raise an error otherwise.  That's not in line with
datetime's philosophy (especially since there's nothing in the time
tuple itself that needs such a range restriction, and other datetime
types might not like this restriction either).

Suggestions?

>     cmp(timeobject, timeobject)

See Tim's post for problems with this; however if the other object
derives from basetime we could return NotImplemented.

>     hash(timeobject)

We would need to agree on how the hash should be computed in such a
way that different datetime objects that compare equal hash the same.
I fear this would be really hard unless we punted and made hash()
return a constant.

> and optionally
> 
>     deltaobject = timeobject - timeobject
>     floatobject = float(deltaobject) # fractional seconds
>     timeobject = timeobject + integerobject
>     timeobject = timeobject + floatobject
>     timeobject = timeobject + deltaobject

The first and last one are already implemented for heterogeneous
operations, and can be implemented by a third party datetime type; I
would be against conversions between ints or floats and
datetime.timedelta, because these don't roundtrip (float doesn't have
enough precision to represent the full range with mucroseconds).

> more here:
> 
>     http://effbot.org/zone/idea-time-type.htm

The proposal also recomments an abstract base type, "basetime", for
all time types.  Without this, cmp() is hard to do (see Tim's post for
explanation; we don't want datetime objects to be comparable to
objects with arbitrary other types, because the default comparison iss
meaningless).

This could be a pure "marker" type, like "basestring".  Marc-Andre,
if we export basetime from the core, can mxDateTime subclass from
that?

--Guido van Rossum (home page: http://www.python.org/~guido/)