Improve non-nanosecond warning

[spencerkclark]

Thanks for the feedback @hmaarrfk. Is this what you had in mind?

• ClosesThe new NON_NANOSECOND_WARNING is not very nice to end users #7237

For example running this script:

importnumpyasnpimportxarrayasxrtimes= [np.datetime64("2000-01-01", "us")]
var=xr.Variable(["time"], times)
da=xr.DataArray(times)

leads to the following warnings:

$ python test_warning.py
test_warning.py:6: UserWarning: Converting non-nanosecond precision datetime values to nanosecond precision. This behavior can eventually be relaxed in xarray, as it is an artifact from pandas which is now beginning to support non-nanosecond precision values. This warning is caused by passing non-nanosecond np.datetime64 or np.timedelta64 values to the DataArray or Variable constructor; it can be silenced by converting the values to nanosecond precision ahead of time.
var = xr.Variable(["time"], times)
test_warning.py:7: UserWarning: Converting non-nanosecond precision datetime values to nanosecond precision. This behavior can eventually be relaxed in xarray, as it is an artifact from pandas which is now beginning to support non-nanosecond precision values. This warning is caused by passing non-nanosecond np.datetime64 or np.timedelta64 values to the DataArray or Variable constructor; it can be silenced by converting the values to nanosecond precision ahead of time.
da = xr.DataArray(times)

[spencerkclark]

Hmm...I was kind of hoping we could avoid something like adding a _stacklevel_increment argument, but hardcoding the stacklevel obviously doesn't work in the case that fields are converted to variables within xarray, e.g. in the case of passing coordinates to the DataArray constructor:

importnumpyasnpimportxarrayasxrtimes= [np.datetime64("2000-01-01", "us")]
da=xr.DataArray([1], dims=["time"], coords=[times])

$ python test_warning.py
/Users/spencer/software/xarray/xarray/core/dataarray.py:148: UserWarning: Converting non-nanosecond precision datetime values to nanosecond precision. This behavior can eventually be relaxed in xarray, as it is an artifact from pandas which is now beginning to support non-nanosecond precision values. This warning is caused by passing non-nanosecond np.datetime64 or np.timedelta64 values to the DataArray or Variable constructor; it can be silenced by converting the values to nanosecond precision ahead of time.
var = as_variable(coord, name=dim)

[hmaarrfk]

Hmm...I was kind of hoping we could avoid something like adding a _stacklevel_increment argument.

Right. thank you for finding that example. I was going to try to construct one.

[dcherian]

.I was kind of hoping we could avoid something like adding a _stacklevel_increment argument,

:( I don't know of any other way.

[mathause]

Pandas has a find_stack_level function (https://github.com/pandas-dev/pandas/blob/0106c26529900bad0561efb9c9180f7f016365b0/pandas/util/_exceptions.py#L28). But I am not sure if this would fix the problem?

[spencerkclark]

Nice find @mathause! That seems to work. I added a version of that function to utils. The warning from my example above now looks like:

test_warning.py:5: UserWarning: Converting non-nanosecond precision datetime values to nanosecond precision. This behavior can eventually be relaxed in xarray, as it is an artifact from pandas which is now beginning to support non-nanosecond precision values. This warning is caused by passing non-nanosecond np.datetime64 or np.timedelta64 values to the DataArray or Variable constructor; it can be silenced by converting the values to nanosecond precision ahead of time.
da = xr.DataArray([1], dims=["time"], coords=[times])

[spencerkclark]

It looks like I've stumbled upon some new upstream test failures related to pandas-dev/pandas#49101.

[keewis]

It looks like I've stumbled upon some new upstream test failures

it's not really new (the CI has been failing since about 4 days ago), but because so many tests fail we're hitting the size limit for new issues:

{"resource":"Issue","code":"custom","field":"body","message":"body is too long (maximum is 65536 characters)"}

Not sure if we can do something about that in the action?

cc @andersy005

[dcherian]

LGTM