[Python-Dev] Interop between datetime and mxDateTime

[Tim Peters]

> Well, I don't see that a basetime marker class alone would
> allow for that.  What else are you assuming?

[Mark Hammond]
> Well, at the very least I expect that I could do *something* <wink>.  If
> I get an object of this type passed to my extension, I at least know it
> is *some* kind of time object, so poke-and-hope can kick in.  There is
> an excellent chance, for example, that a "timetuple()" method exists.

That's a requirement, if the basetime marker is taken as meaning the thing
implements /F's proposal.  But the meaning of timetuple()'s result isn't so
clear, as it contains no time zone info.  The spec says "local time", but
then you lose all info about what time zone the original object believes it
belongs to, and you have to account for your local time's quirks too.  The
spec could say it's a UTC time instead, but then you also lose time zone
info.  Or it could do what datetime actually does, giving you a time tuple
in the local time *of* the datetime object, not the local time on the box
you happen to be running on.  You lose time zone info also that way (there's
a pattern here <wink>:  struct tm simply contains no time zone info).  At
least for a datetime.datetime object, you can call utcoffset() to get the
original object's offset (in minutes east of UTC).

> Certainly being able to deal explicitly only with mxDateTime and Python's
> datetime, without needing to link to either, would still be a huge win.

If that's all you really want, a small chain of isinstance() checks would
suffice.

> So yeah, having more of a datetime *interface* would be nicer
> than a marker type, but given a base type and a clear convention for
> datetime objects, we are pretty close.
>
> On the other hand, I guess *just* the existance of a
> "timetuple()" method is as good an indicator as any.

Provided what timetuple() returns is enough info for your app to live with.
Because of the lack of time zone information, I doubt that it will be, and
for many apps.