NDarray of DateTime

[henon]

          @henon I wouldn't suppose any workarounds exist to getting something like this to work?

NDarray<DateTime> dateTimes = np.array( new DateTime[] {
    new DateTime(2000, 1, 15),
    new DateTime(2000, 6, 15),
    new DateTime(2001, 1, 15),
    new DateTime(2001, 6, 15)
});

Originally posted by @amine-aboufirass in #50 (comment)

[henon]

I don't know. Can you post an equivalent snippet in Python?

[amine-aboufirass]

@henon Well there's multiple ways. I think this is the most idiomatic:

import numpy as np

datetimes = np.array(
    [
        '2000-01-15', 
        '2000-06-15', 
        '2001-01-15',
        '2001-06-15'
    ], 
    dtype='datetime64'
)

print(datetimes.dtype)
print(np.diff(datetimes))

You can also do this:

import numpy as np
from datetime import datetime

datetimes = [
    np.datetime64('2000-01-15'),
    np.datetime64('2000-06-15'),
    np.datetime64('2001-01-15'),
    np.datetime64('2001-06-15')
]

datetimes = np.array(datetimes)

print(np.diff(datetimes).dtype)
print(np.diff(datetimes))

But if I had to emulate the C# as closely as I could, I guess I was attempting something like this:

import numpy as np
from datetime import datetime

datetimes = [
    datetime(2000, 1, 15),
    datetime(2000, 6, 15),
    datetime(2001, 1, 15),
    datetime(2001, 6, 15)
]

datetimes = np.array(datetimes)

print(np.diff(datetimes).dtype)
print(np.diff(datetimes))

So it looks like there's an np.datetime64 type wrapped around datetime from the standard library. Maybe I shouldn't have been trying to access System.DateTime? Perhaps there is already an np.datetime64 equivalent in Numpy.NET?

[henon]

If you know how the date times are represented in memory in numpy (i.e. milliseconds since 1970 or whatever, I really don't know) then you can always use this workaround as described in #115 by creating a byte[] that contains the data which represent the datetimes you want. Of course that is a quite inconvenient workaround.

I'll look into it how I can support date time arrays, maybe I'll have to use the same workaround internally anyway.