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/523#issuecomment-131174556,https://api.github.com/repos/pydata/xarray/issues/523,131174556,MDEyOklzc3VlQ29tbWVudDEzMTE3NDU1Ng==,1217238,2015-08-14T16:40:13Z,2015-08-14T16:40:13Z,MEMBER,"Calendar support is numpy is conceivable, but it will pretty much require fixing numpy dtypes first so that they can be parametrized and extended by third parties in Python (this is on the roadmap). Right now the datetime64 type itself is pretty buggy, in large part because it's written in C code that nobody is maintaining.

.

For pandas, I think the bigger issue is that pandas only does datetime64 with ns resolution. Simply adding us support would go a long ways toward solving this. See here for some discussion on the pandas side: https://github.com/pydata/pandas/issues/7307

On Fri, Aug 14, 2015 at 9:17 AM, Joe Hamman notifications@github.com
wrote:

> > Worth? Yes. Any hope to actually get it in there? No...
> > I think I disagree.  There is almost no chance anyone outside of the climate community is going to spend time on this but, if calendar support was added in a responsible way to numpy and pandas, I don't see why they wouldn't be interested.  So it will need to come from the climate users community, which IMHO, is under represented in the dev community.
> > 
> > ## If you don't want open the issue, I will.
> > 
> > Reply to this email directly or view it on GitHub:
> > https://github.com/xray/xray/pull/523#issuecomment-131166492
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,99847237
https://github.com/pydata/xarray/pull/523#issuecomment-130863487,https://api.github.com/repos/pydata/xarray/issues/523,130863487,MDEyOklzc3VlQ29tbWVudDEzMDg2MzQ4Nw==,1217238,2015-08-13T22:11:51Z,2015-08-13T22:11:51Z,MEMBER,"@ocefpaf To be clear, by ""strongly prefer to get this fix upstream"" I mostly meant that I am reluctant to include this in xray.

I _would_ like it to be straightforward for others to extend our reading capabilities for netcdfs by adding custom logic like this for their own equivalent of `xray.open_dataset` that builds on what we have in xray.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,99847237
https://github.com/pydata/xarray/pull/523#issuecomment-130493686,https://api.github.com/repos/pydata/xarray/issues/523,130493686,MDEyOklzc3VlQ29tbWVudDEzMDQ5MzY4Ng==,1217238,2015-08-13T01:00:28Z,2015-08-13T01:00:28Z,MEMBER,"I would also strongly prefer to get this fix in netCDF4 upstream rather than in xray, if possible.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,99847237