cftime_range does not support default cftime.datetime formatted output strings

Is your feature request related to a problem? Please describe.

The xarray.cftime_range does not support datetime strings that are the default output from cftime.datetime.strftime() which are the format which cftime_range itself uses internally.

import cftime
import xarray
date = cftime.datetime(10,1,1).strftime()
print(date)
xarray.cftime_range(date, periods=3, freq='Y')

outputs

10-01-01 00:00:00
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-70-a16c1fcab8d6> in <module>
      3 date = cftime.datetime(10,1,1).strftime()
      4 print(date)
----> 5 xarray.cftime_range(date, periods=3, freq='Y')

/g/data3/hh5/public/apps/miniconda3/envs/analysis3-20.07/lib/python3.7/site-packages/xarray/coding/cftime_offsets.py in cftime_range(start, end, periods, freq, normalize, name, closed, calendar)
    963 
    964     if start is not None:
--> 965         start = to_cftime_datetime(start, calendar)
    966         start = _maybe_normalize_date(start, normalize)
    967     if end is not None:

/g/data3/hh5/public/apps/miniconda3/envs/analysis3-20.07/lib/python3.7/site-packages/xarray/coding/cftime_offsets.py in to_cftime_datetime(date_str_or_date, calendar)
    683                 "a calendar type must be provided"
    684             )
--> 685         date, _ = _parse_iso8601_with_reso(get_date_type(calendar), date_str_or_date)
    686         return date
    687     elif isinstance(date_str_or_date, cftime.datetime):

/g/data3/hh5/public/apps/miniconda3/envs/analysis3-20.07/lib/python3.7/site-packages/xarray/coding/cftimeindex.py in _parse_iso8601_with_reso(date_type, timestr)
    101 
    102     default = date_type(1, 1, 1)
--> 103     result = parse_iso8601(timestr)
    104     replace = {}
    105 

/g/data3/hh5/public/apps/miniconda3/envs/analysis3-20.07/lib/python3.7/site-packages/xarray/coding/cftimeindex.py in parse_iso8601(datetime_string)
     94         if match:
     95             return match.groupdict()
---> 96     raise ValueError("no ISO-8601 match for string: %s" % datetime_string)
     97 
     98 

ValueError: no ISO-8601 match for string:   10-01-01 00:00:00

Describe the solution you’d like It would be good if xarray.cftime_range supported the default strftime format output from cftime.datetime objects. It is confusing that it uses this format with repr but explicitly does not support it.

Describe alternatives you’ve considered

Specifying an ISO-8601 compatible format (using T separator) isn’t general as it doesn’t work for years < 1000 because the year field is not zero padded.

import cftime
import xarray
date = cftime.datetime(10,1,1).strftime('%Y-%m-%dT%H:%M:%S')
print('|{}|'.format(date))
xarray.cftime_range(date, periods=3, freq='Y')

produces

|  10-01-01T00:00:00|

and the error as above.

A work-around is to zero-pad manually

import cftime
import xarray
date = '{:0>19}'.format(cftime.datetime(10,1,1).strftime('%Y-%m-%dT%H:%M:%S').lstrip())
print(date)
xarray.cftime_range(date, periods=3, freq='Y')

produces

0010-01-01T00:00:00
CFTimeIndex([0010-12-31 00:00:00, 0011-12-31 00:00:00, 0012-12-31 00:00:00], dtype='object')

Additional context I think this is a relatively small addition to the codebase but would make it easier and less confusing to use the default format that is also used by the the function itself. It is easy to support as it is consistent and uniform.

[spencerkclark]

It would be good if xarray.cftime_range supported the default strftime format output from cftime.datetime objects. It is confusing that it uses this format with repr but explicitly does not support it.

@aidanheerdegen see #4343 for a PR that enables this.

[spencerkclark]

Turns zero-padding years is platform dependent.

Oh wow, I didn’t appreciate this; thanks for digging that up.

Thanks for being open to supporting the default output. My only goal is to remove barriers to productivity and remove sources of confusion as I want these tools to be used, and embraced, as widely as possible.

For sure! I can work on a PR for that.