BUG: Series(..) coerces datetime64[non-ns] array differently depending on writable flag

[jorisvandenbossche]

Normally, if we create a Series or DataFrame from a numpy array of non-ns datetime64, and the values are within the ns-range, we convert to datetime64[ns] (in sanitize_array).

However, this does not seem to happen if the array is not writeable:

In [9]: arr = np.array(['2020-01-01T00:00:00.000000'], dtype="datetime64[us]") 

In [10]: pd.Series(arr) 
Out[10]: 
0   2020-01-01
dtype: datetime64[ns]

In [11]: arr.flags.writeable = False  

In [12]: pd.Series(arr)  
Out[12]: 
0    2020-01-01 00:00:00
dtype: object

I suppose this is a bug? (@jbrockmendel ?)

It seems this is due to tslibs.conversion.ensure_datetime64ns failing on a read-only buffer, and it started "failing" since pands 0.25

[jorisvandenbossche]

Fix: #34844. This was caused by #22147 (we really should be more careful with memoryviews, although I suppose we nowadays are).
I quickly skimmed that PR, and most changes there have been fixed in the mean-time (either converted back to use ndarray or added const), a few are remaining, like:

array_strptime (and also array_to_timedelta64 -> to_timedelta)

In [4]: arr = np.array(['15/10/2020'], dtype=object) 

In [5]: arr.flags.writeable = False   

In [6]: pd.to_datetime(arr, format="%d/%m/%Y")    
...
ValueError: buffer source array is read-only

and then a few in parsing.pyx, but I suppose those are generally not a problem, if the arrays are coming from out parsing code, they will never be read-only.

[jbrockmendel]

It seems this is due to tslibs.conversion.ensure_datetime64ns failing on a read-only buffer,

I think this is right. Best guess is this can be fixed by changing the line int64_t[:] ivalues, iresult to two lines const int64_t[:] ivalues, int64_t[:] iresult

[jorisvandenbossche]

Best guess is this can be fixed by changing the line ..

Indeed, already did that ;) -> #34844