[Python-Dev] Interop between datetime and mxDateTime

[M.-A. Lemburg]

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 (nb_float)
> 
> 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/