Thanks for this @jbusecke! Really excited to have this feature in Xarray now.

thanks @jbusecke

Is there anything else that I need to do at this point? Sorry for the xarray noob question...

Awesome. Just added the line. Let me know if you think it is appropriate.

Hello @jbusecke! Thanks for updating the PR.

Cheers ! There are no PEP8 issues in this Pull Request. :beers:

Comment last updated on February 07, 2019 at 13:16 Hours UTC

Thanks. I updated the PR accordingly.

Seems like the travis builds all pass, wohoo. Please let me know if anything else is needed.

I think I have addressed all the above remarks (Many thanks for the thorough review and tips). Waiting for the CI again.

Can you also add line somewhere at the top of plotting.rst saying that cftime plotting is supported once nc-time-axis is installed?

I am smh getting these errors in the backend part of the tests:

``` ======================================================== FAILURES ========================================================= _____ TestNetCDF3ViaNetCDF4Data.test_encoding_same_dtype ______

self = <xarray.tests.test_backends.TestNetCDF3ViaNetCDF4Data object at 0xd238d9a20>

def test_encoding_same_dtype(self):
    ds = Dataset({'x': ('y', np.arange(10.0, dtype='f4'))})
    kwargs = dict(encoding={'x': {'dtype': 'f4'}})
    with self.roundtrip(ds, save_kwargs=kwargs) as actual:

      assert actual.x.encoding['dtype'] == 'f4'

E AssertionError: assert dtype('>f4') == 'f4'

xarray/tests/test_backends.py:853: AssertionError _______ TestGenericNetCDFData.test_encoding_same_dtype ________

self = <xarray.tests.test_backends.TestGenericNetCDFData object at 0xd238e0588>

def test_encoding_same_dtype(self):
    ds = Dataset({'x': ('y', np.arange(10.0, dtype='f4'))})
    kwargs = dict(encoding={'x': {'dtype': 'f4'}})
    with self.roundtrip(ds, save_kwargs=kwargs) as actual:

      assert actual.x.encoding['dtype'] == 'f4'

E AssertionError: assert dtype('>f4') == 'f4'

xarray/tests/test_backends.py:853: AssertionError ``` They do not always show up...not sure what to make of it, but could be an issue with my local environment. Lets see if the CI shows this aswell.

@jbusecke Can you also add nc_time_axis to print_versions() if it is installed?

Ok I think I have most of the things covered. All test pass for me locally. What should I add to the whats-new.rst. I thought of something like this under Enhancements (or would this be considered a bug fix?): Internal plotting now supports cftime.datetime objects as time axis (@spencerkclark, @jbusecke)

I think it would make sense to follow this example, but use cftime.datetime objects instead. You might want to add a test for a 2D plot just to be sure. https://github.com/pydata/xarray/blob/2e99c7dde32e396dd2c5fc6261a2d06217621e10/xarray/tests/test_plot.py#L1797-L1813 Note you'll also need to add nc-time-axis to some CI environments so that things run in some Travis/AppVeyor builds, probably best in: - ci/requirements-py37.yml - ci/requirements-py37-windows.yml

and add some decorators to skip the tests if the needed packages (cftime and nc-time-axis) are not installed. @requires_cftime already exists, but I think you'll have to write your own @requires_nc_time_axis decorator, which you can do, e.g., here: https://github.com/pydata/xarray/blob/2e99c7dde32e396dd2c5fc6261a2d06217621e10/xarray/tests/init.py#L65 Maybe by leaving nc-time-axis out of the py36 test environment (which has cftime) you can use it to test the error message if nc-time-axis is not installed?

Great idea to simplify @spencerkclark. Thanks. Regarding the tests. I have removed the following:

``` @requires_cftime def test_plot_cftime_coordinate_error(): cftime = _import_cftime() time = cftime.num2date(np.arange(5), units='days since 0001-01-01', calendar='noleap') data = DataArray(np.arange(5), coords=[time], dims=['time']) with raises_regex(TypeError, 'requires coordinates to be numeric or dates'): data.plot()

@requires_cftime def test_plot_cftime_data_error(): cftime = _import_cftime() data = cftime.num2date(np.arange(5), units='days since 0001-01-01', calendar='noleap') data = DataArray(data, coords=[np.arange(5)], dims=['x']) with raises_regex(NotImplementedError, 'cftime.datetime'): data.plot() ``` And the test suite passes locally.

But I assume Ill have to add another test dataset with a cftime.datetime time-axis, which then gets dragged through all the plotting tests? Where would I have to put that in?

Many thanks for all the help

I have quickly looked into the testing and found an oddity that might be important if nc-time-axis is not installed.

So in the definition of plot in plot.py I have changed

if contains_cftime_datetimes(darray): to if any([contains_cftime_datetimes(darray[dim]) for dim in darray.dims]): Because if I understand correctly, the previous statement only checks the dtype of the actual data, not the dimensions. Is this appropriate or am I misunderstanding the syntax? In my example above it doesnt matter, because this only spits out an error message when nc-time-axis is not available.

Ok so the plotting works now with both timeseries and 2d data as follows

``` import xarray as xr import numpy as np %matplotlib inline

Create a simple line dataarray with cftime

time = xr.cftime_range(start='2000', periods=4, freq='1H', calendar='noleap') data = np.random.rand(len(time)) da = xr.DataArray(data, coords=[('time', time)]) da.plot() ![download](https://user-images.githubusercontent.com/14314623/51777752-6d427580-20cc-11e9-9c3d-a91d31b10312.png)

Check with 2d data

time = xr.cftime_range(start='2000', periods=6, freq='2MS', calendar='noleap') data2 = np.random.rand(len(time), 4) da2 = xr.DataArray(data2, coords=[('time', time), ('other', range(4))]) da2.plot() ```

Cool. Ill give it a shot right now.

@jbusecke SciTools/nc-time-axis#42 has been merged, and a new release has been made (it's already available on conda-forge)! It would be great if you could update this PR to use this latest version of nc-time-axis -- you should no longer need to convert dates to CalendarDateTime objects.

Thanks again @lbdreyer for your help.

Sounds good to me.

Best

Julius On Jan 23, 2019, 12:56 PM -0500, Spencer Clark notifications@github.com, wrote:

I agree @dcherian; I just pinged the PR again, but if there is no activity there by this time next week, I think we should probably move forward here. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

I agree @dcherian; I just pinged the PR again, but if there is no activity there by this time next week, I think we should probably move forward here.

Looks like upstream hasn't moved. Maybe @jhamman and @spencerkclark can re-ping for a review there?

I am +0.5 on moving forward with an xarray workaround. It seems easy to remove once upstream makes all the required changes.

Is there still interest in this PR? Or did the upstream changes move ahead? I am finding myself explaining workarounds for this too students in the department, so maybe my time would be better invested getting this fix to the full community?

But obviously if things are going to be fixed upstream soon, I would devote time to other projects. Thoughts?

I pinged the met-office folks about your PR. Hopefully that get's merged.

I appreciate it @jhamman; we'll see what happens there.

Oh shoot, I now remember seeing this. If this will be implemented soon I guess the PR can be discarded.

Or this PR could be amended :). We'd still need to make some changes to xarray along the lines of what you've started on here for the optional import of nc-time-axis, addition of cftime.datetime as a plottable type, and updates to the error messages.

Any chance you would have a quick solution for the pcolormesh plot error (second example in the PR)

CalendarDateTime objects are limited in the operations they support, e.g. >= is not supported, which is used in _infer_interval_breaks, which by default is called in xarray's pcolormesh. So this is one place in xarray where being able to use true cftime.datetime objects would really help. Otherwise you'd need to either wait to convert to CalendarDateTime until just before you passed data to a matplotlib function in xarray, or hack _infer_interval_breaks to make it compatible with input arrays of CalendarDateTime objects by converting to them cftime.datetime and back.

If you're in pinch I think things would work here if you passed infer_intervals=False as an argument to plot: python da2.plot(infer_intervals=False) though in general infer_intervals is used for a reason (see https://github.com/pydata/xarray/issues/781#issuecomment-191546524).

Oh shoot, I now remember seeing this. If this will be implemented soon I guess the PR can be discarded. Any chance you would have a quick solution for the pcolormesh plot error (second example in the PR) @spencerkclark?

@spencerkclark - I pinged the met-office folks about your PR. Hopefully that get's merged.

Note I have a PR open in nc-time-axis, which enables plotting of cftime.datetime objects directly (without having to convert to CalendarDateTime objects). This would make this easier in xarray and elsewhere.

That said, I'm not sure if/when it will be merged, so it probably makes sense to go forward with this approach for now.

One of the more general questions I had was if we should expose the conversion using nc-time-axis in the public API. That way users could easily plot the data in matplotlib, e.g.: da_new = da.convert_cftime() plt.plot(da_new.time, da_new) Just an idea...

I have been along the lines of a short example. This works for timeseries data.

``` import xarray as xr import numpy as np %matplotlib inline

Create a simple line dataarray with cftime

time = xr.cftime_range(start='2000', periods=6, freq='2MS', calendar='noleap') data = np.random.rand(len(time)) da = xr.DataArray(data, coords=[('time', time)]) da.plot() ```

For pcolormesh plots this still fails.

```

Create a simple line dataarray with cftime

time = xr.cftime_range(start='2000', periods=6, freq='2MS', calendar='noleap') data2 = np.random.rand(len(time), 4) da2 = xr.DataArray(data2, coords=[('time', time), ('other', range(4))]) da2.plot() ```

Perhaps @spencerkclark has an idea how to deal with differencing cftime.datetime objects?