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

M.-A. Lemburg mal@lemburg.com
Wed, 15 Jan 2003 11:13:53 +0100

Guido van Rossum wrote:

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.

Right (with the new style numbers).

(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).

Doesn't compare use the same coercion scheme as all the other operators ? Ie. if datetimeobject.cmp(datetimeobject, otherobject) returns NotImplemented, wouldn't otherobject.cmp(datetimeobject, otherobject) be called ? (I don't really remember and the rich compares scheme has me pretty confused.)

... 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().

Right; provided I can easily test for the datetime types at C level. That doesn't seem to be easily possible, though, since it requires going through Python to get at the type objects.

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

Oh well.

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

Which APIs are those?

None yet, but these are likely to emerge sooner or later :-)

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.

Not only these. Many third party modules like e.g database modules also work just fine with Unix ticks floats.

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?

Right, but in the long run, this is the right solution.

* compatibility to Unix ticks floats (nbfloat) If you really want that, we could add a float method to datetime, but I see several problems: - What to do if the datetime object's utcoffset() method returns None? Then you can't convert to ticks. I propose an error.

+1

- The range of datetime (1 <= year <= 9999) is much larger than the range of ticks (1970 <= year < 1938). I suppose it could raise an exception when the time is not representable as ticks.

ticks represented as floats have a much larger range and things are moving into that direction as it seems. On Windows they are already using this kind of approach (twisted in the usual MS way, of course).

- A C double doesn't have enough precision for roundtrip guarantees.

True, but then roundtripping isn't guaranteed for many datetime operations anyway. Pretty much the same as with floating point arithmetic in general.

The only roundtripping that needs to be reliable is that of storing broken down values in the type and then retrieving the exact same values. mxDateTime has special provisions for this and also makes sure that COMDates make the roundtrip (as per request from MS COM users).

- Does it really need to be automatic? I.e., does it really need to be float()? I'd be less against this if it was an explicit method, e.g. dt.asposixtime().

Why not both ? (mxDateTime DateTime objects have a .ticks() method for this)

-- Marc-Andre Lemburg CEO eGenix.com Software GmbH

eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/