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/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