issues

• [X] Closes #2304 - but only for my specific use case.
• [x] Tests added

The comments above this line state, "so we just use a float64" but then it returns np.float32. I assume the comments are correct. Changing this also fixes a bug I ran into.

Note that currently, _choose_float_dtype returns float32 if the data is float16 or float32, even if the scale_factor dtype is float64.

• [ ] Closes #xxxx
• [ ] Tests added
• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [ ] New functions/methods are listed in api.rst

_pop_to does a pop operation - it removes the key/value pair. So the line above this change will remove add_offset from attrs if it exists. The second line then checks for add_offset in attrs which should always be False.

This is implemented in #6812 but the work there is significantly more involved (see for example different PR addressing the same problem, #2304), so I'm pulling this fix out and submitting it as its own PR.

What happened:

I have a 10 minute frequency time series. When I resample to hourly it is slow. When I resample to daily it is fast. If I drop to Pandas and resample the speeds are ~100x faster than xarray, and also the same time regardless of the resample period. I've posted this to SO: https://stackoverflow.com/questions/64282393/

What you expected to happen:

I expect xarray to be within an order of magnitude speed of Pandas, not > 2 orders of magnitude slower.

Minimal Complete Verifiable Example:

```python import numpy as np import xarray as xr import pandas as pd import time

size = 10000 times = pd.date_range('2000-01-01', periods=size, freq="10Min") da = xr.DataArray(data = np.random.random(size), dims = ['time'], coords = {'time': times}, name='foo')

start = time.time() da_ = da.resample({'time':"1H"}).mean() print("1H", 'xr', str(time.time() - start))

start = time.time() da_ = da.to_dataframe().resample("1H").mean() print("1H", 'pd', str(time.time() - start), "\n")

start = time.time() da_ = da.resample({'time':"1D"}).mean() print("1D", 'xr', str(time.time() - start))

start = time.time() da_ = da.to_dataframe().resample("1D").mean() print("1D", 'pd', str(time.time() - start)) ```

Output/timings

: 1H xr 0.1761918067932129 : 1H pd 0.0021948814392089844 : : 1D xr 0.00958395004272461 : 1D pd 0.001646280288696289

Anything else we need to know?:

Environment:

Code Sample, a copy-pastable example if possible

I have a simplified NetCDF file with the following header:

```bash

netcdf foo { dimensions: time = UNLIMITED ; // (366 currently) x = 2 ; y = 2 ; variables: float time(time) ; time:standard_name = "time" ; time:long_name = "time" ; time:units = "DAYS since 2000-01-01 00:00:00" ; time:calendar = "standard" ; time:axis = "T" ; ... } ```

I would expect xarray to be able to decode these times. It does, but appears to do so incorrectly and without reporting any issues. Note the fractional time added to each date.

python In [4]: xr.open_dataset('foo.nc').time Out[4]: <xarray.DataArray 'time' (time: 366)> array(['2000-01-01T00:00:00.000000000', '2000-01-02T00:00:00.003211264', '2000-01-03T00:00:00.006422528', ..., '2000-12-29T00:00:01.962606592', '2000-12-30T00:00:01.672216576', '2000-12-31T00:00:01.381826560'], dtype='datetime64[ns]') Coordinates: * time (time) datetime64[ns] 2000-01-01 2000-01-02T00:00:00.003211264 ... Attributes: standard_name: time long_name: time axis: T

Problem description

Days since a valid date on a standard calendar should not add microseconds.

I know that xarray has time issues, for example #118 #521 numpy:#6207 #531 #789 and #848. But all of those appear to address non-standard times. This bug (if it is a bug) seems to occur with a very simple and straight forward calendar, and is silent, so it took me 2 days to figure out what was going on.

Output of xr.show_versions()