html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue https://github.com/pydata/xarray/pull/7827#issuecomment-1567109753,https://api.github.com/repos/pydata/xarray/issues/7827,1567109753,IC_kwDOAMm_X85daDJ5,6628425,2023-05-29T13:00:30Z,2023-05-29T13:00:30Z,MEMBER,"One other tricky edge case that occurs to me is one where an extreme fill value (e.g. `1e30`) is used for floating point fields. If we decode the times first, it might appear that the dates cannot be represented as nanosecond-precision values, but in reality they would be. We may need to think more about how to handle this edge case in addition to #7817.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1700227455 https://github.com/pydata/xarray/pull/7827#issuecomment-1557089270,https://api.github.com/repos/pydata/xarray/issues/7827,1557089270,IC_kwDOAMm_X85cz0v2,6628425,2023-05-22T11:58:18Z,2023-05-22T11:58:18Z,MEMBER,"Great, yeah, that's a nice example without writing to disk. Indeed I saw those warnings too, but omitted them in my earlier message to focus on the encoding issue (sorry about that). I agree that these are something we should address.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1700227455 https://github.com/pydata/xarray/issues/7237#issuecomment-1540065557,https://api.github.com/repos/pydata/xarray/issues/7237,1540065557,IC_kwDOAMm_X85by4kV,6628425,2023-05-09T12:52:54Z,2023-05-09T12:52:54Z,MEMBER,"For a little more discussion of this issue see #7493. As the example at the top of the issue notes, there is at least one place where non-nanosecond times can slip in (this is not intentional), but for most code pathways xarray should currently convert things automatically.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1428549868 https://github.com/pydata/xarray/issues/7237#issuecomment-1540020315,https://api.github.com/repos/pydata/xarray/issues/7237,1540020315,IC_kwDOAMm_X85bythb,6628425,2023-05-09T12:11:24Z,2023-05-09T12:11:24Z,MEMBER,Xarray will convert any non-nanosecond precision times to nanosecond precision (or an error will be raised if this is not possible). ,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1428549868 https://github.com/pydata/xarray/pull/7827#issuecomment-1539086265,https://api.github.com/repos/pydata/xarray/issues/7827,1539086265,IC_kwDOAMm_X85bvJe5,6628425,2023-05-08T21:35:16Z,2023-05-08T21:35:16Z,MEMBER,Thanks @kmuehlbauer -- I just wanted to give you a heads up that I'm pretty busy this week. Hopefully I'll get a free moment to look at this more closely next week.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1700227455 https://github.com/pydata/xarray/issues/7237#issuecomment-1538934080,https://api.github.com/repos/pydata/xarray/issues/7237,1538934080,IC_kwDOAMm_X85bukVA,6628425,2023-05-08T19:35:05Z,2023-05-08T19:35:05Z,MEMBER,"For the time being xarray *should* behave as it always has, converting any non-nanosecond precision times to nanosecond-precision before being used internally.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1428549868 https://github.com/pydata/xarray/issues/7790#issuecomment-1532236037,https://api.github.com/repos/pydata/xarray/issues/7790,1532236037,IC_kwDOAMm_X85bVBEF,6628425,2023-05-02T22:28:52Z,2023-05-02T22:28:52Z,MEMBER,Thanks for the ping @dcherian -- I just gave #7098 a review. I think it's close to ready to merge.,"{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1685803922 https://github.com/pydata/xarray/issues/7794#issuecomment-1528760172,https://api.github.com/repos/pydata/xarray/issues/7794,1528760172,IC_kwDOAMm_X85bHwds,6628425,2023-04-29T11:07:29Z,2023-04-29T11:11:45Z,MEMBER,"The `cftime.Datetime360Day` objects are still expected here. We have not switched over to the universal `cftime.datetime` class yet within xarray, though my sense is this would likely still be an issue regardless (the traceback indicates the error comes up in xarray's indexing logic). `cftime.Datetime360Day` instances are instances of `cftime.datetime` objects: ``` >>> import cftime >>> isinstance(cftime.Datetime360Day(2000, 1, 1), cftime.datetime) True ``` This is the full traceback for reference: ``` Traceback (most recent call last): File """", line 1, in File ""/Users/spencer/software/xarray/xarray/core/dataset.py"", line 1917, in to_netcdf return to_netcdf( # type: ignore # mypy cannot resolve the overloads:( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File ""/Users/spencer/software/xarray/xarray/backends/api.py"", line 1216, in to_netcdf dump_to_store( File ""/Users/spencer/software/xarray/xarray/backends/api.py"", line 1263, in dump_to_store store.store(variables, attrs, check_encoding, writer, unlimited_dims=unlimited_dims) File ""/Users/spencer/software/xarray/xarray/backends/common.py"", line 269, in store variables, attributes = self.encode(variables, attributes) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File ""/Users/spencer/software/xarray/xarray/backends/common.py"", line 358, in encode variables, attributes = cf_encoder(variables, attributes) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File ""/Users/spencer/software/xarray/xarray/conventions.py"", line 773, in cf_encoder _update_bounds_encoding(variables) File ""/Users/spencer/software/xarray/xarray/conventions.py"", line 347, in _update_bounds_encoding ) or contains_cftime_datetimes(v) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File ""/Users/spencer/software/xarray/xarray/core/common.py"", line 1818, in contains_cftime_datetimes return _contains_cftime_datetimes(var._data) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File ""/Users/spencer/software/xarray/xarray/core/common.py"", line 1811, in _contains_cftime_datetimes return isinstance(np.asarray(sample).item(), cftime.datetime) ^^^^^^^^^^^^^^^^^^ File ""/Users/spencer/Software/miniconda3/envs/xarray-tests-py311/lib/python3.11/site-packages/dask/array/core.py"", line 1700, in __array__ x = self.compute() ^^^^^^^^^^^^^^ File ""/Users/spencer/Software/miniconda3/envs/xarray-tests-py311/lib/python3.11/site-packages/dask/base.py"", line 314, in compute (result,) = compute(self, traverse=False, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File ""/Users/spencer/Software/miniconda3/envs/xarray-tests-py311/lib/python3.11/site-packages/dask/base.py"", line 599, in compute results = schedule(dsk, keys, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File ""/Users/spencer/Software/miniconda3/envs/xarray-tests-py311/lib/python3.11/site-packages/dask/threaded.py"", line 89, in get results = get_async( ^^^^^^^^^^ File ""/Users/spencer/Software/miniconda3/envs/xarray-tests-py311/lib/python3.11/site-packages/dask/local.py"", line 511, in get_async raise_exception(exc, tb) File ""/Users/spencer/Software/miniconda3/envs/xarray-tests-py311/lib/python3.11/site-packages/dask/local.py"", line 319, in reraise raise exc File ""/Users/spencer/Software/miniconda3/envs/xarray-tests-py311/lib/python3.11/site-packages/dask/local.py"", line 224, in execute_task result = _execute_task(task, data) ^^^^^^^^^^^^^^^^^^^^^^^^^ File ""/Users/spencer/Software/miniconda3/envs/xarray-tests-py311/lib/python3.11/site-packages/dask/core.py"", line 119, in _execute_task return func(*(_execute_task(a, cache) for a in args)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File ""/Users/spencer/Software/miniconda3/envs/xarray-tests-py311/lib/python3.11/site-packages/dask/array/core.py"", line 120, in getter c = a[b] ~^^^ File ""/Users/spencer/software/xarray/xarray/core/indexing.py"", line 490, in __getitem__ result = self.array[self.indexer_cls(key)] ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^ File ""/Users/spencer/software/xarray/xarray/core/indexing.py"", line 699, in __getitem__ return type(self)(_wrap_numpy_scalars(self.array[key])) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File ""/Users/spencer/software/xarray/xarray/core/indexing.py"", line 686, in __init__ self.array = _wrap_numpy_scalars(as_indexable(array)) ^^^^^^^^^^^^^^^^^^^ File ""/Users/spencer/software/xarray/xarray/core/indexing.py"", line 727, in as_indexable raise TypeError(f""Invalid array type: {type(array)}"") TypeError: Invalid array type: ```","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1688779793 https://github.com/pydata/xarray/pull/7731#issuecomment-1507109914,https://api.github.com/repos/pydata/xarray/issues/7731,1507109914,IC_kwDOAMm_X85Z1Kwa,6628425,2023-04-13T14:50:15Z,2023-04-13T14:50:15Z,MEMBER,Thanks for noting that @dcherian -- I think I got to all of them now.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1657396474 https://github.com/pydata/xarray/pull/7731#issuecomment-1506059299,https://api.github.com/repos/pydata/xarray/issues/7731,1506059299,IC_kwDOAMm_X85ZxKQj,6628425,2023-04-12T22:42:26Z,2023-04-12T22:42:26Z,MEMBER,Thanks all for the help! Fingers crossed things should be all green now. Happy to address any more review comments.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1657396474 https://github.com/pydata/xarray/pull/7731#issuecomment-1499107154,https://api.github.com/repos/pydata/xarray/issues/7731,1499107154,IC_kwDOAMm_X85ZWo9S,6628425,2023-04-06T13:57:56Z,2023-04-06T13:57:56Z,MEMBER,I'm fine waiting until #7724 is merged to let our main CI cover this. Indeed the upstream tests are flaky. Locally I just installed pandas 2 via pip to do testing during development. ,"{""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1657396474 https://github.com/pydata/xarray/issues/7716#issuecomment-1498321082,https://api.github.com/repos/pydata/xarray/issues/7716,1498321082,IC_kwDOAMm_X85ZTpC6,6628425,2023-04-06T00:16:46Z,2023-04-06T00:16:46Z,MEMBER,Thanks @keewis -- I went ahead and added some more detailed thoughts about how to address the cftime-related failures in #7707. I can try to address those soon.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1654022522 https://github.com/pydata/xarray/issues/7707#issuecomment-1498209121,https://api.github.com/repos/pydata/xarray/issues/7707,1498209121,IC_kwDOAMm_X85ZTNth,6628425,2023-04-05T21:58:06Z,2023-04-06T00:11:46Z,MEMBER,"I think it is fine that `CFTimeIndex.to_datetimeindex()` no longer raises an error for out-of-nanosecond-precision range dates, so we can simply relax that test for pandas versions greater than or equal to 2 and update its docstring. In practice I don't think this will come up very often (we can address later if we want probably), but one subtle issue there is that prior to October 15th, 1582, the proleptic Gregorian calendar and the ""standard"" calendar are not equivalent, so we may want to update [how we warn when converting between calendars](https://github.com/pydata/xarray/blob/84607c3b1d61e3bc2d4b07b4f12f41a40b027f6f/xarray/coding/cftimeindex.py#L640-L649). The ""standard"" calendar [according to the CF Conventions](https://cfconventions.org/Data/cf-conventions/cf-conventions-1.10/cf-conventions.html#calendar) is a mixed Julian/Gregorian calendar, which uses a Julian calendar prior to 1582-10-15 and a Gregorian calendar after. In cftime the `DatetimeGregorian` object conforms to this definition, and is what is created if you provide `""standard""` as the `calendar` argument to `num2date`: ``` >>> cftime.num2date([0, 1], units=""days since 1582-10-04"", calendar=""standard"") array([cftime.DatetimeGregorian(1582, 10, 4, 0, 0, 0, 0, has_year_zero=False), cftime.DatetimeGregorian(1582, 10, 15, 0, 0, 0, 0, has_year_zero=False)], dtype=object) >>> cftime.num2date([0, 1], units=""days since 1582-10-04"", calendar=""proleptic_gregorian"") array([cftime.DatetimeProlepticGregorian(1582, 10, 4, 0, 0, 0, 0, has_year_zero=True), cftime.DatetimeProlepticGregorian(1582, 10, 5, 0, 0, 0, 0, has_year_zero=True)], dtype=object) ``` I'll need to think more about how to handle the `test_should_cftime_be_used_source_outside_range` failure; I'm not sure if we're ready to handle changing the behavior of this until we fully address #7493.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1650481625 https://github.com/pydata/xarray/issues/7716#issuecomment-1497629183,https://api.github.com/repos/pydata/xarray/issues/7716,1497629183,IC_kwDOAMm_X85ZRAH_,6628425,2023-04-05T14:54:39Z,2023-04-05T14:54:39Z,MEMBER,"The cftime-related ones are still pandas related, but hopefully should be straightforward to address.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1654022522 https://github.com/pydata/xarray/pull/7441#issuecomment-1492956264,https://api.github.com/repos/pydata/xarray/issues/7441,1492956264,IC_kwDOAMm_X85Y_LRo,6628425,2023-04-01T12:22:31Z,2023-04-01T12:22:31Z,MEMBER,Thanks for cleaning up the merge error I must have introduced; I agree this should be ready to go.,"{""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 1, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1533980729 https://github.com/pydata/xarray/pull/7441#issuecomment-1492724527,https://api.github.com/repos/pydata/xarray/issues/7441,1492724527,IC_kwDOAMm_X85Y-Ssv,6628425,2023-03-31T23:41:20Z,2023-03-31T23:41:20Z,MEMBER,Thanks @keewis for fixing this upstream (https://github.com/pandas-dev/pandas/pull/52220)!,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1533980729 https://github.com/pydata/xarray/pull/7441#issuecomment-1465318583,https://api.github.com/repos/pydata/xarray/issues/7441,1465318583,IC_kwDOAMm_X85XVvy3,6628425,2023-03-12T22:37:20Z,2023-03-12T22:37:20Z,MEMBER,"Still mulling this over a bit, but one other thing that occurs to me is that if we go with a `strftime` solution we should be careful (if it exists) to preserve any sub-second information of the Timestamp as well.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1533980729 https://github.com/pydata/xarray/issues/7609#issuecomment-1464917740,https://api.github.com/repos/pydata/xarray/issues/7609,1464917740,IC_kwDOAMm_X85XUN7s,6628425,2023-03-11T13:58:20Z,2023-03-11T13:58:20Z,MEMBER,Answered in #7610.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1619929803 https://github.com/pydata/xarray/pull/7444#issuecomment-1460423854,https://api.github.com/repos/pydata/xarray/issues/7444,1460423854,IC_kwDOAMm_X85XDEyu,6628425,2023-03-08T16:07:39Z,2023-03-08T16:07:39Z,MEMBER,Thanks @keewis -- I pushed a fix. The documentation build succeeded. The other build failures look unrelated.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1535387692 https://github.com/pydata/xarray/pull/7441#issuecomment-1460037064,https://api.github.com/repos/pydata/xarray/issues/7441,1460037064,IC_kwDOAMm_X85XBmXI,6628425,2023-03-08T11:46:04Z,2023-03-08T11:46:04Z,MEMBER,"Hmm I guess I should have run the tests before saying anything. We could probably work around the `NaT` issue fairly easily, but I forgot about timezones. The ability to include a colon in the UTC offset, which we expect in the failing test, with `strftime` was only recently added to Python (https://github.com/python/cpython/pull/95983), which makes things a little messier. I'll think about this a little more.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1533980729 https://github.com/pydata/xarray/pull/7441#issuecomment-1459255349,https://api.github.com/repos/pydata/xarray/issues/7441,1459255349,IC_kwDOAMm_X85W-ng1,6628425,2023-03-08T03:08:31Z,2023-03-08T03:08:31Z,MEMBER,Thanks @keewis--great suggestion--I think this should be ready for review now too!,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1533980729 https://github.com/pydata/xarray/pull/7444#issuecomment-1459195989,https://api.github.com/repos/pydata/xarray/issues/7444,1459195989,IC_kwDOAMm_X85W-ZBV,6628425,2023-03-08T02:34:37Z,2023-03-08T02:34:37Z,MEMBER,@keewis and @dcherian indeed I just wanted to give it another once over. I think it should be ready for review now. Thanks for your patience on this!,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1535387692 https://github.com/pydata/xarray/issues/7504#issuecomment-1419032191,https://api.github.com/repos/pydata/xarray/issues/7504,1419032191,IC_kwDOAMm_X85UlLZ_,6628425,2023-02-06T12:51:38Z,2023-02-06T12:51:38Z,MEMBER,"Indeed currently we do not support indexing a CFTimeIndex-backed array using a list of strings, but that's something I think we would be happy to change (e.g. we do accept a list of strings to `interp` for CFTimeIndex-backed arrays). For the time being you should be able to use `cftime.DatetimeAllLeap` values themselves: ```python ds.sel(time=[cftime.DatetimeAllLeap(2023, 1, 1), cftime.DatetimeAllLeap(2023, 1, 2)]) ``` ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1572434353 https://github.com/pydata/xarray/pull/7373#issuecomment-1416848107,https://api.github.com/repos/pydata/xarray/issues/7373,1416848107,IC_kwDOAMm_X85Uc2Lr,6628425,2023-02-04T20:55:55Z,2023-02-04T20:55:55Z,MEMBER,After debugging locally it looks like the remaining doc build failure was the result of a line I inadvertently deleted further down in the `cftime_range` docstring. It should be good now I think.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1489128898 https://github.com/pydata/xarray/issues/7493#issuecomment-1412908603,https://api.github.com/repos/pydata/xarray/issues/7493,1412908603,IC_kwDOAMm_X85UN0Y7,6628425,2023-02-01T23:37:28Z,2023-02-01T23:37:39Z,MEMBER,"Currently in xarray we make the choice based on the calendar attribute associated with the data on disk (following the CF conventions). If the data has a non-standard calendar (or cannot be represented with nanosecond-precision datetime values) then we use cftime; otherwise we use NumPy. Which kind of calendar do PMIP simulations typically use? For some background -- my initial need in this realm came mainly from idealized climate model simulations (e.g. configured to start on 0001-01-01 with a no-leap calendar), so I do not have a ton of experience with paleoclimate research. I would be happy to learn more about your application, however!","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1563104480 https://github.com/pydata/xarray/issues/7493#issuecomment-1412439718,https://api.github.com/repos/pydata/xarray/issues/7493,1412439718,IC_kwDOAMm_X85UMB6m,6628425,2023-02-01T17:25:00Z,2023-02-01T18:54:41Z,MEMBER,"Thanks for joining the meeting today @khider. Some potentially relevant places in the code that come to my mind are: - [Automatic casting to nanosecond precision](https://github.com/pydata/xarray/blob/67d0ee20f66517627a2ce795b650b980dd982de9/xarray/core/variable.py#L176-L287) - [Decoding times via pandas](https://github.com/pydata/xarray/blob/67d0ee20f66517627a2ce795b650b980dd982de9/xarray/coding/times.py#L215-L259) - [Encoding times via pandas](https://github.com/pydata/xarray/blob/67d0ee20f66517627a2ce795b650b980dd982de9/xarray/coding/times.py#L613-L669) - [`datetime_to_numeric`](https://github.com/pydata/xarray/blob/67d0ee20f66517627a2ce795b650b980dd982de9/xarray/core/duck_array_ops.py#L441-L499) Though as @shoyer says, searching for `datetime64[ns]` or `timedelta64[ns]` will probably go a long way toward finding most of these issues. Some design questions that come to my mind are (but you don't need an answer to these immediately to start working): - How do we decide which precision to decode times to? Would it be the finest precision that enables decoding without overflow? - This is admittedly in the weeds, but how do we decide when to use cftime and when not to? It seems obvious that in the long term we should use NumPy values for proleptic Gregorian dates of all precisions, but what about dates from the Gregorian calendar (where we may no longer have the luxury that the proleptic Gregorian and Gregorian calendars are equivalent for all representable times)? - Not a blocker (since this is an existing issue) but are there ways we could make working with mixed precision datetime values friendlier with regard to overflow (https://github.com/numpy/numpy/issues/16352)? I worry about examples like this: ``` >>> np.seterr(over=""raise"") >>> np.datetime64(""1970-01-01"", ""ns"") - np.datetime64(""0001-01-01"", ""D"") numpy.timedelta64(6795364578871345152,'ns') ```","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1563104480 https://github.com/pydata/xarray/issues/7493#issuecomment-1412267822,https://api.github.com/repos/pydata/xarray/issues/7493,1412267822,IC_kwDOAMm_X85ULX8u,6628425,2023-02-01T15:38:59Z,2023-02-01T15:38:59Z,MEMBER,Great -- I'll plan on joining. That's correct. It is at 8:30 AM PT (https://github.com/pydata/xarray/issues/4001).,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1563104480 https://github.com/pydata/xarray/issues/7493#issuecomment-1412244849,https://api.github.com/repos/pydata/xarray/issues/7493,1412244849,IC_kwDOAMm_X85ULSVx,6628425,2023-02-01T15:24:33Z,2023-02-01T15:24:33Z,MEMBER,I can block out time to join today's meeting or an upcoming one if it would be helpful.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1563104480 https://github.com/pydata/xarray/issues/7493#issuecomment-1410846692,https://api.github.com/repos/pydata/xarray/issues/7493,1410846692,IC_kwDOAMm_X85UF8_k,6628425,2023-01-31T18:08:11Z,2023-01-31T18:08:11Z,MEMBER,@dcherian +1. I'm happy to engage with others if they are motivated to start on this earlier.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1563104480 https://github.com/pydata/xarray/issues/7493#issuecomment-1410236770,https://api.github.com/repos/pydata/xarray/issues/7493,1410236770,IC_kwDOAMm_X85UDoFi,6628425,2023-01-31T12:08:10Z,2023-01-31T12:08:10Z,MEMBER,"Indeed it would be nice if this ""just worked"" but it may take some time to sort out (sorry that this example initially got your hopes up!). Here what I mean by ""address"" is continuing to prevent non-nanosecond-precision datetime values from entering xarray through casting to nanosecond precision and raising an informative error if that is not possible. This of course would be temporary until we work through the kinks of enabling such support. In the big picture it is exciting that pandas is doing this in part due to your grant.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1563104480 https://github.com/pydata/xarray/issues/7493#issuecomment-1409661324,https://api.github.com/repos/pydata/xarray/issues/7493,1409661324,IC_kwDOAMm_X85UBbmM,6628425,2023-01-31T02:44:22Z,2023-01-31T02:44:22Z,MEMBER,"Thanks for posting this general issue @khider. This is something that has been on my radar for several months and I'm on board with it being great to support (eventually this will likely help cftime support as well). I might hesitate to say that I'm actively working on it yet 😬. Right now, in the time I have available, I'm mostly trying to make sure that xarray's existing functionality does not break under pandas 2.0. Once things are a little more stable in pandas with regard to this new feature my plan is to take a deeper dive into what it will take to adopt in xarray (some aspects might need to be handled delicately). We can plan on using this issue for more discussion. As @keewis notes, xarray currently will cast any non-nanosecond precision `datetime64` or `timedelta64` values that are introduced to nanosecond-precision versions. This casting machinery goes through pandas, however, and I haven't looked carefully into how this is behaving/is expected to behave under pandas 2.0. @khider based on your nice example it seems that it is possible for non-nanosecond-precision values to slip through, which is something we may need to think about addressing for the time being.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1563104480 https://github.com/pydata/xarray/pull/7373#issuecomment-1407672926,https://api.github.com/repos/pydata/xarray/issues/7373,1407672926,IC_kwDOAMm_X85T52Je,6628425,2023-01-29T14:04:55Z,2023-01-29T14:04:55Z,MEMBER,Thanks for the help @keewis and @dcherian. I think this should be ready for a full review.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1489128898 https://github.com/pydata/xarray/issues/7467#issuecomment-1400379742,https://api.github.com/repos/pydata/xarray/issues/7467,1400379742,IC_kwDOAMm_X85TeBle,6628425,2023-01-23T13:47:30Z,2023-01-23T13:47:30Z,MEMBER,(Obviously the above comment only applies if cftime installed; technically cftime is an optional dependency),"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1552630830 https://github.com/pydata/xarray/issues/7467#issuecomment-1400370743,https://api.github.com/repos/pydata/xarray/issues/7467,1400370743,IC_kwDOAMm_X85Td_Y3,6628425,2023-01-23T13:42:50Z,2023-01-23T13:46:59Z,MEMBER,@yurivict could you show the output of `xarray.show_versions()`? I suspect you are using an old version of cftime. Xarray requires a minimum version of 1.5.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1552630830 https://github.com/pydata/xarray/pull/7461#issuecomment-1398773751,https://api.github.com/repos/pydata/xarray/issues/7461,1398773751,IC_kwDOAMm_X85TX5f3,6628425,2023-01-20T18:24:53Z,2023-01-20T18:24:53Z,MEMBER,"@jhamman nice -- thanks for noting that. I think you can replace `timedeltas` with `unique_timedeltas` here: https://github.com/pydata/xarray/blob/b21f62ee37eea3650a58e9ffa3a7c9f4ae83006b/xarray/coding/times.py#L365 and then remove any reference to `timedeltas` in the rest of the function.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1550109629 https://github.com/pydata/xarray/pull/7441#issuecomment-1397354953,https://api.github.com/repos/pydata/xarray/issues/7441,1397354953,IC_kwDOAMm_X85TSfHJ,6628425,2023-01-19T17:33:16Z,2023-01-19T17:33:16Z,MEMBER,"Issue reported here: https://github.com/pandas-dev/pandas/issues/50867. Thanks again for noting that @keewis. I was too narrowly focused on fixing this in xarray. We may still want to be careful about non-nanosecond-precision `Timestamp` objects leaking into our code for the time being, but that's a different conversation.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1533980729 https://github.com/pydata/xarray/pull/7441#issuecomment-1397286186,https://api.github.com/repos/pydata/xarray/issues/7441,1397286186,IC_kwDOAMm_X85TSOUq,6628425,2023-01-19T16:45:24Z,2023-01-19T17:16:31Z,MEMBER,"Thanks @keewis. > I think this is a bug in pandas: pd.Timestamp(""1-01-01 00:00:00"") returns a date in 2001. I suspect this may be related to the comment [here](https://github.com/pydata/xarray/blob/6c5840e1198707cdcf7dc459f27ea9510eb76388/xarray/coding/times.py#L124-L128). > In any case, t.isoformat(sep="" "") should return the year with 4 digits so maybe we should use that instead? (once again, it doesn't, but that I think is also a bug, maybe the same one?) Though indeed the `isoformat` behavior is definitely a bug and it would be fair to at least expect this kind of roundtrip to hold, but it doesn't: ``` >>> import pandas as pd >>> pd.Timestamp(str(pd.Timestamp(""0001-01-01""))) Timestamp('2001-01-01 00:00:00') ``` I can report that to pandas. It's not necessarily surprising considering that it previously was not possible to write `pd.Timestamp(""0001-01-01"")`. ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1533980729 https://github.com/pydata/xarray/issues/7420#issuecomment-1383240645,https://api.github.com/repos/pydata/xarray/issues/7420,1383240645,IC_kwDOAMm_X85ScpPF,6628425,2023-01-15T20:12:32Z,2023-01-15T20:12:32Z,MEMBER,"After a git bisect I traced the units encoding errors to https://github.com/pandas-dev/pandas/pull/49737. I made a PR to address this in xarray (#7441), but it turns out this change may be reverted in pandas (https://github.com/pandas-dev/pandas/issues/50704) so I would hold off on reviewing it until a decision is made there.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1519784328 https://github.com/pydata/xarray/issues/7420#issuecomment-1371626497,https://api.github.com/repos/pydata/xarray/issues/7420,1371626497,IC_kwDOAMm_X85RwVwB,6628425,2023-01-05T01:21:33Z,2023-01-05T01:21:33Z,MEMBER,"#7373 should take care of the `date_range` errors and https://github.com/pydata/xarray/issues/7266#issuecomment-1336172648 is my thinking on how to address the `base` deprecation. I'll have to look into what's causing the other datetime-related errors. Apologies I haven't much time to work on these issues lately. Hopefully some time should free up for me towards the end of next week.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1519784328 https://github.com/pydata/xarray/pull/7361#issuecomment-1347554206,https://api.github.com/repos/pydata/xarray/issues/7361,1347554206,IC_kwDOAMm_X85QUgue,6628425,2022-12-13T00:07:51Z,2022-12-13T00:07:51Z,MEMBER,"Yes, I think that's what we'll end up going with @mroeschke. Thanks for your patience as we worked it out.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1477931237 https://github.com/pydata/xarray/pull/7361#issuecomment-1345679164,https://api.github.com/repos/pydata/xarray/issues/7361,1345679164,IC_kwDOAMm_X85QNW88,6628425,2022-12-11T22:50:57Z,2022-12-11T22:50:57Z,MEMBER,"Technically I think we would consider `get_loc` to be public (both due to how it is named and in that [it is at least primitively documented](https://docs.xarray.dev/en/stable/generated/xarray.CFTimeIndex.get_loc.html#xarray.CFTimeIndex.get_loc)). That said, I don't know how many people use the lower level methods of CFTimeIndexes like `get_loc` outside of xarray data structures. My inclination is that it would not require a deprecation cycle, given the warning had already been being raised as in the example above. It's true though that this warning was not being emitted in the case that `key` was a string, so perhaps it's a little borderline. Maybe @dcherian or @mathause, do you have any thoughts?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1477931237 https://github.com/pydata/xarray/issues/7266#issuecomment-1336172648,https://api.github.com/repos/pydata/xarray/issues/7266,1336172648,IC_kwDOAMm_X85PpGBo,6628425,2022-12-03T14:36:44Z,2022-12-03T14:36:44Z,MEMBER,"As I think about this more, it wouldn't be too hard for us to support the `base` argument even after pandas removes it, so perhaps this isn't so urgent (at least as far as deprecation is concerned; we still need to make updates for compatibility, however). The code to translate a `base` argument to an `offset` argument can be found [here](https://github.com/pandas-dev/pandas/blob/bca35ff73f101b29106111703021fccc8781be7a/pandas/core/resample.py#L1668-L1678), and is all possible with public API functionality. I already did something similar for the CFTimeIndex resampling code in #7284. Maybe you were already thinking along those lines @dcherian.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1440280424 https://github.com/pydata/xarray/issues/7266#issuecomment-1335971694,https://api.github.com/repos/pydata/xarray/issues/7266,1335971694,IC_kwDOAMm_X85PoU9u,6628425,2022-12-02T23:56:55Z,2022-12-02T23:56:55Z,MEMBER,"Sorry I didn't get to adding the warning today. I'll try and put something together over the weekend so that it gets into the release after today's. I'm not sure exactly when pandas 2.0 will be out, but regardless I guess at least it could still be valuable for anyone who doesn't upgrade xarray and pandas at the same time.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1440280424 https://github.com/pydata/xarray/issues/7266#issuecomment-1335139569,https://api.github.com/repos/pydata/xarray/issues/7266,1335139569,IC_kwDOAMm_X85PlJzx,6628425,2022-12-02T12:03:27Z,2022-12-02T12:04:20Z,MEMBER,"Should we add some sort of deprecation warning regarding the use of the `base` argument with future versions of pandas before the next release? (I did not end up restoring the pandas warning in #7284)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1440280424 https://github.com/pydata/xarray/issues/7266#issuecomment-1312768623,https://api.github.com/repos/pydata/xarray/issues/7266,1312768623,IC_kwDOAMm_X85OP0Jv,6628425,2022-11-13T16:21:28Z,2022-11-13T16:21:28Z,MEMBER,Perhaps we can at least restore the warning in #7284 in case our next release happens to take place before the next pandas release to give users somewhat of a heads up. Apologies for being a bit out of the loop of #4292 at the time.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1440280424 https://github.com/pydata/xarray/issues/7266#issuecomment-1312767572,https://api.github.com/repos/pydata/xarray/issues/7266,1312767572,IC_kwDOAMm_X85OPz5U,6628425,2022-11-13T16:16:52Z,2022-11-13T16:16:52Z,MEMBER,"I went ahead and actually implemented the `origin` and `offset` options for the `CFTimeIndex` version of resample as part of #7284. It might be good to finish that and then we can decide how we would like to handle the deprecation. > Maybe we should try to catch Deprecation warnings in the nightly builds and raise an error / Automatic issue, so we can fix things before they break. I agree -- something like that would be useful in general. In this particular case it seems like we were aware of it at one point, but just lost track after silencing it initially for compatibility reasons (https://github.com/pydata/xarray/pull/4292#issuecomment-691665611). Unfortunately that means that this was silenced in user code as well.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1440280424 https://github.com/pydata/xarray/issues/6985#issuecomment-1312756623,https://api.github.com/repos/pydata/xarray/issues/6985,1312756623,IC_kwDOAMm_X85OPxOP,6628425,2022-11-13T15:28:18Z,2022-11-13T15:28:18Z,MEMBER,Thanks for pinging this issue again in #7266 -- apologies for missing it earlier. I think we should adapt to the new `inclusive` argument and implement it for the `cftime_range` function as well.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1361246796 https://github.com/pydata/xarray/issues/7266#issuecomment-1308705176,https://api.github.com/repos/pydata/xarray/issues/7266,1308705176,IC_kwDOAMm_X85OAUGY,6628425,2022-11-09T12:52:11Z,2022-11-09T12:53:13Z,MEMBER,"Yes, I think so too. I can look into it more this weekend. Clearly we need to change the code that relies on pandas immediately. For resampling with a `CFTimeIndex` I may create a separate issue for implementing these new arguments (we can probably get those tests passing in the meantime, however).","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1440280424 https://github.com/pydata/xarray/pull/7238#issuecomment-1303356166,https://api.github.com/repos/pydata/xarray/issues/7238,1303356166,IC_kwDOAMm_X85Nr6MG,6628425,2022-11-04T12:07:19Z,2022-11-04T12:07:19Z,MEMBER,It looks like I've stumbled upon some new upstream test failures related to https://github.com/pandas-dev/pandas/pull/49101.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1428748922 https://github.com/pydata/xarray/pull/7238#issuecomment-1303303334,https://api.github.com/repos/pydata/xarray/issues/7238,1303303334,IC_kwDOAMm_X85NrtSm,6628425,2022-11-04T11:39:44Z,2022-11-04T11:39:44Z,MEMBER,"Nice find @mathause! That seems to work. I added a version of that function to `utils`. The warning from [my example above](https://github.com/pydata/xarray/pull/7238#issuecomment-1296235033) 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]) ```","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1428748922 https://github.com/pydata/xarray/pull/7238#issuecomment-1296235033,https://api.github.com/repos/pydata/xarray/issues/7238,1296235033,IC_kwDOAMm_X85NQvoZ,6628425,2022-10-30T11:56:00Z,2022-10-30T11:56:00Z,MEMBER,"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: ```python import numpy as np import xarray as xr times = [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) ```","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1428748922 https://github.com/pydata/xarray/pull/7201#issuecomment-1291296935,https://api.github.com/repos/pydata/xarray/issues/7201,1291296935,IC_kwDOAMm_X85M96Cn,6628425,2022-10-26T00:59:01Z,2022-10-26T00:59:01Z,MEMBER,"> For good measure I also added some assertions that the dtypes after conversion were all of nanosecond precision. ...which turned up a case that was not valid under the existing pandas version, so I added another separate test.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1419972576 https://github.com/pydata/xarray/pull/7201#issuecomment-1291275729,https://api.github.com/repos/pydata/xarray/issues/7201,1291275729,IC_kwDOAMm_X85M903R,6628425,2022-10-26T00:22:20Z,2022-10-26T00:22:20Z,MEMBER,Thanks @dcherian -- I did my best to try and cover our bases. For good measure I also added some assertions that the dtypes after conversion were all of nanosecond precision. ,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1419972576 https://github.com/pydata/xarray/issues/7197#issuecomment-1288107349,https://api.github.com/repos/pydata/xarray/issues/7197,1288107349,IC_kwDOAMm_X85MxvVV,6628425,2022-10-23T12:58:32Z,2022-10-23T12:58:32Z,MEMBER,No worries @djhoese. I should be able to submit a PR implementing https://github.com/pydata/xarray/issues/7175#issuecomment-1281254828 later today. ,"{""total_count"": 3, ""+1"": 3, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1419602897 https://github.com/pydata/xarray/pull/7171#issuecomment-1281676688,https://api.github.com/repos/pydata/xarray/issues/7171,1281676688,IC_kwDOAMm_X85MZNWQ,6628425,2022-10-18T00:58:17Z,2022-10-18T00:58:17Z,MEMBER,Thanks @dcherian — yes it probably would be good to create an issue to track further discussion about this. Encoding times with float128 values might be of interest to some. I’ll create one tomorrow.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1410574596 https://github.com/pydata/xarray/issues/7175#issuecomment-1281665629,https://api.github.com/repos/pydata/xarray/issues/7175,1281665629,IC_kwDOAMm_X85MZKpd,6628425,2022-10-18T00:37:31Z,2022-10-18T00:37:31Z,MEMBER,"Yes, I think that’s the safest approach on our side to start out.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1410693563 https://github.com/pydata/xarray/issues/7175#issuecomment-1280748702,https://api.github.com/repos/pydata/xarray/issues/7175,1280748702,IC_kwDOAMm_X85MVqye,6628425,2022-10-17T12:02:42Z,2022-10-17T12:02:42Z,MEMBER,"This is neat to be honest. I think this is related to more progress on enabling different precision datetimes and timedeltas in pandas ([issues](https://github.com/pandas-dev/pandas/issues?q=is%3Aissue+label%3ANon-Nano+) and [PRs](https://github.com/pandas-dev/pandas/pulls?q=is%3Apr+label%3ANon-Nano+) related to the ""Non-nano"" effort). We'll have to read more about how they plan to roll this out and figure out how we will adapt in xarray.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1410693563 https://github.com/pydata/xarray/issues/7145#issuecomment-1278206409,https://api.github.com/repos/pydata/xarray/issues/7145,1278206409,IC_kwDOAMm_X85ML-HJ,6628425,2022-10-13T21:39:21Z,2022-10-13T21:39:21Z,MEMBER,@durack1 I guess the answer is [today](https://github.com/pydata/xarray/releases/tag/v2022.10.0) thanks to @dcherian :).,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1401909544 https://github.com/pydata/xarray/pull/7147#issuecomment-1275347589,https://api.github.com/repos/pydata/xarray/issues/7147,1275347589,IC_kwDOAMm_X85MBEKF,6628425,2022-10-11T22:26:26Z,2022-10-11T22:27:36Z,MEMBER,Thanks for taking a look @dcherian. This should at least handle any exceptions raised by `decode_cf_variable` (which could be more than just time-related).,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1402017668 https://github.com/pydata/xarray/issues/6906#issuecomment-1250058482,https://api.github.com/repos/pydata/xarray/issues/6906,1250058482,IC_kwDOAMm_X85KgmDy,6628425,2022-09-17T12:00:26Z,2022-09-17T12:20:41Z,MEMBER,"I was able to reproduce this issue in a Docker container using the [s390x Debian image](https://hub.docker.com/r/s390x/debian/). After a little experimentation I narrowed it down to the following minimal example: ``` >>> import numpy as np; import pandas as pd >>> np.__version__ '1.23.3' >>> pd.__version__ '1.4.4' >>> pd.Series(np.array([1]).astype("""", line 1, in File ""/usr/local/lib/python3.9/dist-packages/pandas/core/series.py"", line 451, in __init__ data = sanitize_array(data, index, dtype, copy) File ""/usr/local/lib/python3.9/dist-packages/pandas/core/construction.py"", line 570, in sanitize_array subarr = _try_cast(data, dtype, copy, raise_cast_failure) File ""/usr/local/lib/python3.9/dist-packages/pandas/core/construction.py"", line 729, in _try_cast return sanitize_to_nanoseconds(arr, copy=copy) File ""/usr/local/lib/python3.9/dist-packages/pandas/core/dtypes/cast.py"", line 1717, in sanitize_to_nanoseconds values = conversion.ensure_datetime64ns(values) File ""pandas/_libs/tslibs/conversion.pyx"", line 257, in pandas._libs.tslibs.conversion.ensure_datetime64ns File ""pandas/_libs/tslibs/np_datetime.pyx"", line 120, in pandas._libs.tslibs.np_datetime.check_dts_bounds pandas._libs.tslibs.np_datetime.OutOfBoundsDatetime: Out of bounds nanosecond timestamp: 8220291319602-05-05 16:00:00 ``` This confirms it is an upstream issue. Interestingly if we use the native byte order (big-endian on this architecture) for the dtype, this example works: ``` >>> pd.Series(np.array([1]).astype(""M8[h]"")) 0 1970-01-01 01:00:00 dtype: datetime64[ns] ``` or more explicitly ``` >>> pd.Series(np.array([1]).astype("">M8[h]"")) 0 1970-01-01 01:00:00 dtype: datetime64[ns] ``` It appears the inverse of this issue (big-endian dtype leading to a failure on a little-endian system) came up once in pandas: https://github.com/pandas-dev/pandas/issues/29684. @amckinstry I'm not sure what it will take to fix this issue in pandas, but you are welcome to open an issue there. They may also have a difficult time reproducing and testing this, however (https://github.com/pandas-dev/pandas/pull/30976#issuecomment-573989082).","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1334835539 https://github.com/pydata/xarray/pull/6940#issuecomment-1242718333,https://api.github.com/repos/pydata/xarray/issues/6940,1242718333,IC_kwDOAMm_X85KEmB9,6628425,2022-09-10T12:28:16Z,2022-09-10T12:28:16Z,MEMBER,Oops sorry I missed the merge conflict. Thanks @dcherian and @mathause.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1345573285 https://github.com/pydata/xarray/pull/6988#issuecomment-1241756493,https://api.github.com/repos/pydata/xarray/issues/6988,1241756493,IC_kwDOAMm_X85KA7NN,6628425,2022-09-09T09:50:55Z,2022-09-09T09:50:55Z,MEMBER,Thanks @mathause for reviewing.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1361886569 https://github.com/pydata/xarray/issues/6906#issuecomment-1241339308,https://api.github.com/repos/pydata/xarray/issues/6906,1241339308,IC_kwDOAMm_X85J_VWs,6628425,2022-09-08T23:38:29Z,2022-09-08T23:38:29Z,MEMBER,"Interesting. Thanks for checking that #6988 indeed solves this. I went ahead and merged it, but when I get a chance I’ll keep trying to track down the root cause of this issue. ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1334835539 https://github.com/pydata/xarray/pull/6988#issuecomment-1241337041,https://api.github.com/repos/pydata/xarray/issues/6988,1241337041,IC_kwDOAMm_X85J_UzR,6628425,2022-09-08T23:34:20Z,2022-09-08T23:34:20Z,MEMBER,"I will go ahead and merge this. I think it’s a positive change regardless, and it’s nice it also helps with #6906.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1361886569 https://github.com/pydata/xarray/issues/6906#issuecomment-1237014040,https://api.github.com/repos/pydata/xarray/issues/6906,1237014040,IC_kwDOAMm_X85Ju1YY,6628425,2022-09-05T13:18:21Z,2022-09-05T13:18:21Z,MEMBER,"Thanks @amckinstry. I guess my last try to produce a pandas minimal example might be: ``` >>> import numpy as np; import pandas as pd >>> pd.Series(np.array([np.int64(1000000).astype("">> import numpy as np; import pandas as pd >>> pd.Series(np.int64(1000000).astype("">> import numpy as np; import pandas as pd >>> pd.Series(pd.Timestamp(np.int64(1000000).astype("" It looks like we can bump to 2021.08.0 instead of dealing with this compatibility code. Thanks for noting this @dcherian. I wasn't sure if this was worth bumping our minimum version for, but since our policy allows for it, I'm happy to make that change.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1345573285 https://github.com/pydata/xarray/pull/6940#issuecomment-1221642349,https://api.github.com/repos/pydata/xarray/issues/6940,1221642349,IC_kwDOAMm_X85I0Mht,6628425,2022-08-21T23:24:06Z,2022-08-21T23:24:06Z,MEMBER,"Ah, this still didn't quite work for older dask versions:

``` ====================================================================================================== FAILURES ======================================================================================================= ___________________________________________________________________________________________ test_cftime_datetime_mean[True] ___________________________________________________________________________________________ dask = True @requires_cftime @pytest.mark.parametrize(""dask"", [False, True]) def test_cftime_datetime_mean(dask): if dask and not has_dask: pytest.skip(""requires dask"") times = cftime_range(""2000"", periods=4) da = DataArray(times, dims=[""time""]) da_2d = DataArray(times.values.reshape(2, 2)) if dask: da = da.chunk({""time"": 2}) da_2d = da_2d.chunk({""dim_0"": 2}) expected = da.isel(time=0) # one compute needed to check the array contains cftime datetimes with raise_if_dask_computes(max_computes=1): > result = da.isel(time=0).mean() /Users/spencer/software/xarray/xarray/tests/test_duck_array_ops.py:342: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ /Users/spencer/software/xarray/xarray/core/_reductions.py:1478: in mean return self.reduce( /Users/spencer/software/xarray/xarray/core/dataarray.py:2930: in reduce var = self.variable.reduce(func, dim, axis, keep_attrs, keepdims, **kwargs) /Users/spencer/software/xarray/xarray/core/variable.py:1854: in reduce data = func(self.data, **kwargs) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ array = dask.array, axis = None, skipna = None, kwargs = {} _contains_cftime_datetimes = , offset = dask.array timedeltas = dask.array, mean_timedeltas = dask.array def mean(array, axis=None, skipna=None, **kwargs): """"""inhouse mean that can handle np.datetime64 or cftime.datetime dtypes"""""" from .common import _contains_cftime_datetimes array = asarray(array) if array.dtype.kind in ""Mm"": offset = _datetime_nanmin(array) # xarray always uses np.datetime64[ns] for np.datetime64 data dtype = ""timedelta64[ns]"" return ( _mean( datetime_to_numeric(array, offset), axis=axis, skipna=skipna, **kwargs ).astype(dtype) + offset ) elif _contains_cftime_datetimes(array): offset = min(array) timedeltas = datetime_to_numeric(array, offset, datetime_unit=""us"") mean_timedeltas = _mean(timedeltas, axis=axis, skipna=skipna, **kwargs) > return _to_pytimedelta(mean_timedeltas, unit=""us"") + offset E TypeError: unsupported operand type(s) for +: 'Array' and 'Array' /Users/spencer/software/xarray/xarray/core/duck_array_ops.py:573: TypeError ```

This appears to be the commit that fixed this issue in dask, meaning it should be fixed as of dask version 2021.07.0: ``` git bisect broken 626cc724ffa1d14cd74f48ff4f21ef443d832afa is the first fixed commit commit 626cc724ffa1d14cd74f48ff4f21ef443d832afa Author: Julia Signell Date: Tue Jun 29 11:50:36 2021 -0400 Allow mixing dask and numpy arrays in @guvectorize (#6863) dask/array/core.py | 7 ++++++- dask/array/tests/test_gufunc.py | 11 +++++++++++ 2 files changed, 17 insertions(+), 1 deletion(-) ```","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1345573285 https://github.com/pydata/xarray/issues/6906#issuecomment-1221528092,https://api.github.com/repos/pydata/xarray/issues/6906,1221528092,IC_kwDOAMm_X85Izwoc,6628425,2022-08-21T11:37:47Z,2022-08-21T11:37:47Z,MEMBER,"Apologies for taking a while to look into this. I have not been able to set up an environment to reproduce these test failures, which makes it tricky. It seems like the tests are failing in the setup step, where a DataArray of some random times is generated: ``` data = xr.DataArray(np.random.randint(1, 1000000, size=(4, 5)).astype("">> import numpy as np; import pandas as pd >>> pd.Timestamp(np.int64(1000000).astype("">> import numpy as np >>> import xarray as xr >>> xr.coding.times.decode_cf_datetime(np.uint32(50), ""seconds since 2018-08-22T03:23:03Z"") array('2018-08-22T03:23:05.755359744', dtype='datetime64[ns]') ``` I believe the solution is to also cast all unsigned integer values -- anything with `dtype.kind == ""u""` -- to `np.int64` values here: https://github.com/pydata/xarray/blob/770e878663b03bd83d2c28af0643770bdd43c3da/xarray/coding/times.py#L220-L224 Ordinarily we might worry about overflow in this context -- i.e. some `np.uint64` values cannot be represented by `np.int64` values -- but I believe since [we already verify that the minimum and maximum value of the input array can be represented by nanosecond-precision timedelta values](https://github.com/pydata/xarray/blob/770e878663b03bd83d2c28af0643770bdd43c3da/xarray/coding/times.py#L217-L218), we can safely do this.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1231399637 https://github.com/pydata/xarray/issues/4183#issuecomment-1112047474,https://api.github.com/repos/pydata/xarray/issues/4183,1112047474,IC_kwDOAMm_X85CSH9y,6628425,2022-04-28T10:34:20Z,2022-04-28T10:34:20Z,MEMBER,This issue was addressed as part of https://github.com/pydata/xarray/pull/4684. ,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,646038170 https://github.com/pydata/xarray/issues/6453#issuecomment-1100895150,https://api.github.com/repos/pydata/xarray/issues/6453,1100895150,IC_kwDOAMm_X85BnlOu,6628425,2022-04-17T14:55:56Z,2022-04-17T14:55:56Z,MEMBER,"After a little more investigating I think I've narrowed this down to the following example. This particular example happens to be problematic even with the development version of xarray (i.e. it is an existing bug): ``` In [1]: import pandas as pd ...: import xarray as xr In [2]: times = pd.date_range(""2000"", periods=2) In [3]: variable = xr.Variable([""time""], times) In [4]: variable.encoding Out[4]: {} In [5]: xr.conventions.decode_cf_variable(variable).encoding Out[5]: {'dtype': dtype(' Here when I want to retrieve the year of datetime, instead of casting back to an array of object & using datetime.year, it's handy to use built-in numpy datetime64 conversion. The recommended way to extract datetime components, like the year, is to use the [`DatetimeAccessor`](https://docs.xarray.dev/en/stable/generated/xarray.core.accessor_dt.DatetimeAccessor.html). For example if you have a DataArray of datetime-like values (whether they are of type `np.datetime64[ns]` or `cftime.datetime`) you can do something like this: ``` da.dt.year ``` and it will return a DataArray containing the year of each datetime (for more information see the [""Datetime components""](https://docs.xarray.dev/en/stable/user-guide/time-series.html#datetime-components) section of the documentation).","{""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 1, ""rocket"": 0, ""eyes"": 0}",,1180565228 https://github.com/pydata/xarray/issues/6412#issuecomment-1078904879,https://api.github.com/repos/pydata/xarray/issues/6412,1078904879,IC_kwDOAMm_X85ATsgv,6628425,2022-03-25T10:59:49Z,2022-03-25T10:59:49Z,MEMBER,"This is a common point of confusion, but is in fact expected. Xarray intentionally converts any `np.datetime64` type to `np.datetime64[ns]`. The primary motivation is compatibility with pandas, which xarray relies on for time indexing and other time-related operations through things like `pandas.DatetimeIndex` or the `pandas.Series.dt` accessor (see, e.g., discussion in https://github.com/pydata/xarray/issues/789). May I ask what your reason is for requiring a lower-precision datetime type? In xarray we have tried to provide alternatives (e.g. [through `cftime`](https://docs.xarray.dev/en/stable/user-guide/weather-climate.html#non-standard-calendars-and-dates-outside-the-timestamp-valid-range)) for use-cases like longer date ranges.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1180565228 https://github.com/pydata/xarray/pull/6368#issuecomment-1072813115,https://api.github.com/repos/pydata/xarray/issues/6368,1072813115,IC_kwDOAMm_X84_8dQ7,6628425,2022-03-18T21:21:20Z,2022-03-18T21:21:20Z,MEMBER,Thanks again @okhoma -- welcome to xarray!,"{""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 1, ""rocket"": 0, ""eyes"": 0}",,1171069302 https://github.com/pydata/xarray/issues/6318#issuecomment-1059832700,https://api.github.com/repos/pydata/xarray/issues/6318,1059832700,IC_kwDOAMm_X84_K8N8,6628425,2022-03-05T21:19:17Z,2022-03-05T21:19:17Z,MEMBER,"I did a little more digging. I'm not a backend expert, but I think the issue can be distilled to the following. When passed an ordinary NumPy array as an input, `xarray.Variable` will automatically cast any `np.datetime64` values to nanosecond precision: ``` In [3]: arr = np.array([np.datetime64(""2000-01-01"", ""us"")]) In [4]: xarray.Variable([""time""], arr) Out[4]: array(['2000-01-01T00:00:00.000000000'], dtype='datetime64[ns]') ``` However, if passed a `LazilyIndexedArray`, this casting will not occur (note the dtype is still `'datetime64[us]'`): ``` In [5]: lazily_indexed_arr = xarray.core.indexing.LazilyIndexedArray(arr) In [6]: xarray.Variable([""time""], lazily_indexed_arr) Out[6]: array(['2000-01-01T00:00:00.000000'], dtype='datetime64[us]') ``` This is based on [this code](https://github.com/pydata/xarray/blob/f42ac28629b7b2047f859f291e1d755c36f2e834/xarray/backends/zarr.py#L404-L419) within `xarray.backends.zarr.ZarrStore`. The casting does not occur in the `Variable` constructor, because it requires the type of the array be `np.ndarray` -- see [here](https://github.com/pydata/xarray/blob/f42ac28629b7b2047f859f291e1d755c36f2e834/xarray/core/variable.py#L233-L234). Regardless, even if we relaxed that, `_possibly_convert_objects` would raise an error, because it is not compatible with `LazilyIndexedArray` objects. Is this something that we maybe need to address within the xarray zarr backend? As I understand it, zarr is a bit unusual compared to other storage formats we deal with in that it can store and open `np.datetime64` data directly -- normally datetime data starts as some numeric type and is converted to datetime data after going through our decoding pipeline.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1157163377 https://github.com/pydata/xarray/issues/6318#issuecomment-1056924176,https://api.github.com/repos/pydata/xarray/issues/6318,1056924176,IC_kwDOAMm_X84-_2IQ,6628425,2022-03-02T13:20:23Z,2022-03-02T13:20:23Z,MEMBER,"To be honest I didn't know it was possible to open a Dataset and maintain `np.datetime64[us]` values. I feel like casting maybe should occur automatically -- we do this already in other contexts, e.g.: ``` In [3]: da = xr.DataArray([np.datetime64(""2000-01-01"", ""us"")], dims=[""time""], name=""time"") In [4]: da Out[4]: array(['2000-01-01T00:00:00.000000000'], dtype='datetime64[ns]') Dimensions without coordinates: time ``` I'll try and dig deeper into this in the next few days, but @keewis's workaround should be good in the meantime.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1157163377 https://github.com/pydata/xarray/issues/6226#issuecomment-1026812348,https://api.github.com/repos/pydata/xarray/issues/6226,1026812348,IC_kwDOAMm_X849M-m8,6628425,2022-02-01T12:55:34Z,2022-02-01T12:55:34Z,MEMBER,"Awesome, thanks @antarcticrainforest -- yes, it will always have an object `dtype`.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1120276279 https://github.com/pydata/xarray/issues/6226#issuecomment-1026701337,https://api.github.com/repos/pydata/xarray/issues/6226,1026701337,IC_kwDOAMm_X849MjgZ,6628425,2022-02-01T10:39:28Z,2022-02-01T10:39:28Z,MEMBER,"Thanks @antarcticrainforest -- I think that's exactly what @mathause is getting at. It seems fairly safe to add a new keyword argument to `CFTimeIndex.__new__`, and the example @mathause uses would make a nice test. Would either of you be up to make a PR?","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1120276279 https://github.com/pydata/xarray/issues/6026#issuecomment-1012153521,https://api.github.com/repos/pydata/xarray/issues/6026,1012153521,IC_kwDOAMm_X848VDyx,6628425,2022-01-13T13:49:27Z,2022-01-13T13:49:27Z,MEMBER,Great! I'll go ahead and close this issue.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1063046540 https://github.com/pydata/xarray/pull/5876#issuecomment-1010114336,https://api.github.com/repos/pydata/xarray/issues/5876,1010114336,IC_kwDOAMm_X848NR8g,6628425,2022-01-11T16:06:33Z,2022-01-11T16:06:33Z,MEMBER,Thanks @pierreloicq!,"{""total_count"": 3, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 1, ""confused"": 0, ""heart"": 1, ""rocket"": 0, ""eyes"": 0}",,1030492705 https://github.com/pydata/xarray/pull/5876#issuecomment-1008312049,https://api.github.com/repos/pydata/xarray/issues/5876,1008312049,IC_kwDOAMm_X848GZ7x,6628425,2022-01-09T14:51:33Z,2022-01-09T17:53:08Z,MEMBER,"@dcherian @mathause @andersy005 given a DataArray of times with missing values, do you have any thoughts on what the preferred result of `da.dt.season` would be? One option would be to return `np.nan` in place of the missing time values: ``` In [3]: times = [np.datetime64(""NaT""), np.datetime64(""2000-01-01"")] In [4]: da = xr.DataArray(times, dims=[""x""]) In [5]: da.dt.season Out[5]: array([nan, 'DJF'], dtype=object) Dimensions without coordinates: x ``` This would be somewhat in line with how pandas handles this in other contexts (e.g. https://github.com/pydata/xarray/pull/5876#discussion_r734447120). But this sort of awkwardly returns a DataArray of mixed types. Another option, and this is how @pierreloicq implemented things originally, would be to simply return a string label for missing values, e.g. ``` In [5]: da.dt.season Out[5]: array(['nan', 'DJF'], dtype=' Given the increasing scope of cftime-related utilities, I wonder if it would make sense to try to eventually move the cftime-related utilities outside of Xarray into a separate package? After the current ongoing ""explicit indexes"" refactor, I believe we will have public APIs for all of the essential functionality. Yeah, I think that could be something good to strive for, and it's exciting that the explicit indexes refactor could facilitate that. To be clear, are you ok with merging #5233 and waiting until after the refactor is complete to discuss future plans there?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,857947050 https://github.com/pydata/xarray/issues/5889#issuecomment-950392205,https://api.github.com/repos/pydata/xarray/issues/5889,950392205,IC_kwDOAMm_X844pdWN,6628425,2021-10-24T20:45:36Z,2021-10-24T20:45:36Z,MEMBER,"It would be cool if we could merge #5233 before the next release as well. I think it is ready, and @aulemahal has been diligently working on it for the last several months (and been very patient with my sporadic reviewing frequency).","{""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1034238626 https://github.com/pydata/xarray/pull/5723#issuecomment-950239817,https://api.github.com/repos/pydata/xarray/issues/5723,950239817,IC_kwDOAMm_X844o4JJ,6628425,2021-10-24T00:51:33Z,2021-10-24T00:51:33Z,MEMBER,@mathause I think this should be ready now. I added some version-dependent logic to the tests.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,976108741