D extensions to python, inline in an ipython/jupyter notebook

[Laeeth Isharc via Digitalmars-d-announce]

> Aren't there time-zone concerns? Or is this just a mapping 
> between D's std.datetime.DateTime and python's 
> datetime.datetime with tzinfo==None, i.e. a naive date?
>
> Also, there would have to be some serious warning signs about 
> translating from python to D, in that the micro-seconds will be 
> truncated. Doesn't a lack of microseconds make it unusable for 
> tick data?

https://docs.python.org/3/c-api/datetime.html

The Python API has microseconds passed as an int in last 
argument.  You're right that I hadn't considered that D DateTime 
doesn't have fractions of a second (I think), so a SysTime would 
be better.

On the other hand, I think datetime.datetime and numpy datetime64 
are timezone-free.  There are libraries that implement datetimes 
with a timezone.

So sensible options are:

1. datetime.datetime<->std.datetime.DateTime throwing away 
fractions of a second for python -> D.
2. datetime.datetime<->std.datetime.SysTime presuming python time 
is UTC and
2a) throwing away SysTime timezone and assuming it is UTC
2b) converting SysTime to a UTC time (and presuming python time 
is UTC).

I would go for 1 as default and allowing 2b as an option.  The 
problem is that if you implement the mapping in the pyd main code 
then user cannot override it in custom conversion code because it 
is only called if the inbuilt conversion fails.

So maybe 2b is the only sensible feasible option.