The correct place to fix this is almost certainly a lower-level C function rather than adding a special case to the high-level wrapper.

The RuntimeError is coming from NpyDatetime_MakeISO8601Datetime, I'd start by looking at how that function is being called in a C debugger to understand where the bug is coming from.

I would think that string casts just behave different from item coercion. FWIW, I am not sure I am convinced we should even make this work. Is it really useful to allow such unclear conversions to begin with?

FWIW, I am not sure I am convinced we should even make this work. Is it really useful to allow such unclear conversions to begin with?

Apparently I made it work when I added support for StringDType. The issue has a test script that illustrates this.

It'd be nice if there wasn't this weird inconsistency between StringDType and the fixed-width string dtypes.

It'd be nice if there wasn't this weird inconsistency between StringDType and the fixed-width string dtypes.

I am not sure I am following. I thought what is triggering is that one path for the old string dtype fails because the date can't be correctly inserted (it gets truncated), while the scalar assignment doesn't.
(Probably, because the scalar assignment does the exactly what this does.)

But, I am not sure why that matters for StringDType. StringDType doesn't have a length limitation, so it always succeeds and that is OK.
I.e. the non-stringDType code paths behave exactly the same in NumPy 1.24.

I am not sure I am following. I thought what is triggering is that one path for the old string dtype fails because the date can't be correctly inserted (it gets truncated), while the scalar assignment doesn't.
(Probably, because the scalar assignment does the exactly what this does.)

Ah, that makes more sense, I didn't understand the subtlety that there was a truncation issue going on.

I agree then, there might not be anything to fix.

Hi @ngoldbaum and @seberg,

Thank you for your feedback, and I apologize if my previous changes introduced any ambiguity. Let me clarify the core issue:

• There is no problem with StringDType (works as expected).
• The issue occurs specifically when inserting a zero-dimensional np.datetime64 array (wrapped in a 0D array) into a string scalar.However the same operation works fine with an unwrapped np.datetime64 scalar.

Although with unwrapped np.datetime64, the result is problematic due to truncation:

>>> np.insert('5', 0, np.datetime64('2025-10-10'))
output we got :-   array(['2', '5'], dtype='<U1')

My initial approach was to make 0D arrays behave like scalars (to fix the inconsistency), but I understand the concern about whether this should be handled at the C level or avoided entirely.

Is this logic acceptable as it is, or would it be better to move it to the C layer (e.g., NpyDatetime_MakeISO8601Datetime)? Or is this behavior inherently undesirable?

Please let me know If we do fix it, should we also address the truncation issue, or deprecate such conversions altogether?

I am not sure I am following. I thought what is triggering is that one path for the old string dtype fails because the date can't be correctly inserted (it gets truncated), while the scalar assignment doesn't.
(Probably, because the scalar assignment does the exactly what this does.)

But, I am not sure why that matters for StringDType. StringDType doesn't have a length limitation, so it always succeeds and that is OK.
I.e. the non-stringDType code paths behave exactly the same in NumPy 1.24.

Yes, exactly — since StringDType is not fixed-width, it’s expected that it doesn’t raise any issues here. The problem seems to lie in how truncation happens when using the str dtype.

As @AnkitAhlawat7742 pointed out, the issue occurs specifically when inserting a 0D np.datetime64 array into a string scalar — this fails, while inserting an unwrapped np.datetime64 scalar works but leads to silent truncation (e.g., array(['2', '5'], dtype='<U1')).
It would be great if this could either be fixed or clarified as expected behavior.

My point is that I generally don't like the truncating behavior much and I don't think it serves anyone making it work more often. The error seems usually like the better thing. This is a rare code path, data is lost, so forcing users to jump through hoops and casting themselves is good.

I would be fine with deprecating the scalar assignment to strings here. While it is a discussion that we should probably have, it is a bigger discussion probably, because it is what we do with most scalar assignments to strings right now.
However, I would be happy to entertain a PR that deprecates string truncation on scalar assignment.
(Another subtlety is that string->string casts also truncates silently, although that can be prevented with "safe" casting.)

Mainly, I am not convinced about moving towards being more forgiving here when being forgiving looks like a bug magnet.