issues: 860511053
This data as json
id | node_id | number | title | user | state | locked | assignee | milestone | comments | created_at | updated_at | closed_at | author_association | active_lock_reason | draft | pull_request | body | reactions | performed_via_github_app | state_reason | repo | type |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
860511053 | MDExOlB1bGxSZXF1ZXN0NjE3Mzc4MjUz | 5180 | Convert calendar to lowercase in standard calendar checks | 6628425 | closed | 0 | 0 | 2021-04-17T20:44:57Z | 2021-04-18T10:17:11Z | 2021-04-18T10:17:08Z | MEMBER | 0 | pydata/xarray/pulls/5180 | This fixes the issue in #5093, by ensuring that we always convert the calendar to lowercase before checking if it is one of the standard calendars in the decoding and encoding process. I've been careful to test that the calendar attribute is faithfully roundtripped despite this, uppercase letters and all. ~~I think part of the reason this went unnoticed for a while was that we could still decode times like this if cftime was installed; it is only in the case when cftime was not installed that our logic failed. This is because Upon re-reading @pont-us's issue description, while it didn't cause an error, the behavior was incorrect with cftime installed too. I updated the test to check the dtype is
|
{ "url": "https://api.github.com/repos/pydata/xarray/issues/5180/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
13221727 | pull |