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?

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.

Reply via email to