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.
