This change is incorrect; the warning indicates a real bug, and this fixes the warning but not the bug.

The problem is that in the loop below, there's a two-step string->datetime64 conversion: it goes string->`npy_datetimestruct`->datetime64. `dt` is used both as the temporary buffer for the datetime64 value, and also as a flag for whether the first step failed and the second step needs to be run. What turns this into a mess is that it's never reset -- so if the first step ever fails, then the second step is disabled *for the entire rest of the loop*. The whole logic should be changed really -- first there should be one block of logic that sets up a pointer to a usable buffer, and then we should do something like
```
if (parse_iso_8601_datetime(src, tmp - src,
                                 d->dst_meta.base, NPY_SAME_KIND_CASTING,
                                 &dts, NULL, NULL, NULL) < 0) {
    dt = NPY_DATETIME_NAT;
}
else if (convert_datetimestruct_to_datetime(&d->dst_meta, &dts, &dt) < 0)
    dt = NPY_DATETIME_NAT;
}
```
(The key thing being that uses the error condition on the first step directly to determine whether torun the second step, rather than trying to communicate this through `dt`.

Example of buggy behaviour in current master:
```
>>> dates = np.zeros(3, dtype="datetime64[D]")
>>> dates
array(['1970-01-01', '1970-01-01', '1970-01-01'], dtype='datetime64[D]')
>>> dates[:] = np.asarray(["2012-01-01", "", "2012-01-01"])
>>> dates
array(['2012-01-01', 'NaT', 'NaT'], dtype='datetime64[D]')
```
(last entry should be `'2012-01-01'`, not `'NaT'`.