[Python-Dev] Interop between datetime and mxDateTime

[Guido van Rossum]

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

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

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

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

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