Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'standard' calendar refers to 'proleptic_gregorian' in cftime_range rather than 'gregorian' #2761

Closed
spencerkclark opened this issue Feb 11, 2019 · 2 comments

Comments

@spencerkclark
Copy link
Member

Code Sample, a copy-pastable example if possible

In [1]: import xarray

In [2]: xarray.cftime_range('2000', periods=3, calendar='standard').values
Out[2]:
array([cftime.DatetimeProlepticGregorian(2000, 1, 1, 0, 0, 0, 0, -1, 1),
       cftime.DatetimeProlepticGregorian(2000, 1, 2, 0, 0, 0, 0, -1, 1),
       cftime.DatetimeProlepticGregorian(2000, 1, 3, 0, 0, 0, 0, -1, 1)],
      dtype=object)

Problem description

When writing cftime_range I used dates from a proleptic Gregorian calendar when the calendar type was specified as 'standard'. While this is consistent with Python's built-in datetime.datetime (which uses a proleptic Gregorian calendar), this differs from the behavior in cftime.num2date and ultimately the CF conventions, which state that 'standard' should refer to the true Gregorian calendar. My inclination is that considering "cf" is in the name of cftime_range, we should adhere to those conventions as closely as possible (and hence the way I initially coded things was a mistake).

Expected Output

In [2]: xarray.cftime_range('2000', periods=3, calendar='standard').values
Out[2]:
array([cftime.DatetimeGregorian(2000, 1, 1, 0, 0, 0, 0, -1, 1),
       cftime.DatetimeGregorian(2000, 1, 2, 0, 0, 0, 0, -1, 1),
       cftime.DatetimeGregorian(2000, 1, 3, 0, 0, 0, 0, -1, 1)],
      dtype=object)

Do others agree that we should fix this? If we were to make this change, would it be appropriate to consider it a bug and simply make the breaking change immediately, or might we need a deprecation cycle?

@shoyer
Copy link
Member

shoyer commented Feb 13, 2019

Yes, I think we can consider this a bug and just fix it.

@spencerkclark
Copy link
Member Author

Sounds good; see #2771.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants