[Python-Dev] Interop between datetime and mxDateTime (original) (raw)

Tim Peters tim.one@comcast.net
Mon, 13 Jan 2003 21:04:27 -0500

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