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

Guido van Rossum guido@python.org
Tue, 14 Jan 2003 12:29:34 -0500

An abstract baseclass would only help all the way if I can make mxDateTime objects new style classes. That's not going to happen for a few months because I don't have any requirement for it.

OK, but see below.

Now for interop, I'm basically interested in adding support for most of the binary operations ...

mxD = mx.DateTime.DateTime mxDD = mx.DateTime.DateTimeDelta dt = datetime t = timedelta d = date * mxD - d (assuming 0:00 as time part), mxD - dt * mxD -/+ t * mxDD + d (assuming 0:00 as time part), mxDD + dt * mxDD -/+ t * mxD < d * mxDD < t

These you can all do.

(and reverse order)

That is also doable, except for the comparisons. That's why I was proposing that you inherit from basetime. The datetime module's comparison currently always raises TypeError when the other argument isn't a datetime instance; my proposal would be to return NotImplemented if the other isn't a datetime instance but it inherits from basetime.

I guess an alternative would be to check whether the other argument "smells like" a time object, e.g. by testing for a "timetuple" attribute (or whatever we agree on).

... and contructors

* DateTimeFrom(dt), DateTimeFrom(d) * DateTimeDeltaFrom(t) etc.

You should be able to do that. You should get dt.timetuple(), which gives time in dt's local time (not your local time), and then you can convert it to UTC by subtracting dt.utcoffset().

In order to get the binary ops to work, I'll have to enable new style number support in mxDateTime and drop the 1.5.2 support :-(

Time to bite that bullet. :-)

Now the problem I see is when an API expects a datetime object and gets an mxDateTime object instead.

Which APIs are those?

For mxDateTime I have solved this by simply letting float(mxD) return a Unix ticks value and float(mxDD) return the value in seconds since midnight -- this makes mxDateTime object compatible to all APIs which have previously only accepted Unix ticks.

You mean time.ctime(x), time.localtime(x), and time.gmtime(x)? Those operations are available as methods on datetime objects, though with different names and (in the case of localtime) with somewhat different semantics when timezones are involved.

mxDateTime also does mixed type operations using Unix ticks if it doesn't know the other type.

So perhaps we need something like this: * a basedate class which is accessible at C level

Um, I thought you just said you couldn't do a base class yet?

* compatibility to Unix ticks floats (nbfloat)

If you really want that, we could add a float method to datetime, but I see several problems:

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