rename "Y" freq string to "YE" (pandas parity)

[mathause]

• Adresses point 1 of more frequency string updates? #8612
• Fixes one of the failures in ⚠️ Nightly upstream-dev CI failed ⚠️ #8623
• Tests added
• User visible changes (including notable bug fixes) are documented in whats-new.rst

This renames the frequency string "Y" (formerly "A") to "YE" to achieve pandas parity. It could be better to wait for the conclusion of pandas-dev/pandas#56840 before doing this (but fixing the related failure in #8623 seemed a good reason as any to do it know).

Let me know what you think @spencerkclark @aulemahal

[spencerkclark]

Thanks @mathause for keeping up on this. This makes sense to me!

[spencerkclark]

I think you may need to realign the edge of the table for the doc build to pass:

Suggested change

	| Y(E,S)-JAN | Annual frequency, anchored at the (end, beginning) of January |
	| Y(E,S)-JAN | Annual frequency, anchored at the (end, beginning) of January |

[max-sixty]

This does fix most of the tests. Are we OK to merge in its current state and fix the remaining breakages in another PR?

[spencerkclark]

I tentatively prefer to wait until @mathause has a chance to fully wrap this up (I think it should be quick).

[max-sixty]

I tentatively prefer to wait until @mathause has a chance to fully wrap this up (I think it should be quick).

OK. I do think we should really try and not having things in a failing state. I know it's not easy.

More generally — we did have deprecation warnings on the cftime code for months now — I understand that everyone is a volunteer and it's difficult to ask specific people to do the work to prevent these sorts of outcomes. But possibly this sort of outcome — where all the test jobs are failing for multiple days — should update us to doing less in the main xarray library...

---

I think I've fixed all the non-cftime issues (mostly through workarounds)

[spencerkclark]

@max-sixty I hear your frustration / concern, and I am sorry that this happened. I must admit though that the first time I saw this failure was in #8623, which was opened only a couple days before this breaking version of pandas was released. This was tricky to catch ahead of time, because the return value for infer_freq in pandas changed abruptly without a deprecation cycle (and the change was made after my work in #8415):

pandas 2.1.4

>>> pd.__version__
'2.1.4'
>>> pd.infer_freq(pd.date_range("2000", periods=10, freq="A-FEB"))
'A-FEB'

pandas 2.2.0

>>> pd.__version__
'2.2.0'
>>> pd.infer_freq(pd.date_range("2000", periods=10, freq="A-FEB"))
<stdin>:1: FutureWarning: 'A-FEB' is deprecated and will be removed in a future version, please use 'YE-FEB' instead.
'YE-FEB'

Deprecation warnings in the main test suite

The deprecation warnings in our main test suite in the preceding months were not relevant to this particular case. I was aware of those warnings in #8415, but did not address them at the time for the following reason from the PR description:

I also took the liberty to transition to using "Y", "YS", "h", "min", "s", "ms", "us", and "ns" within our code, tests, and documentation to reduce the amount of warnings emitted. I have held off on switching to "QE", "ME", and anchored offsets involving "Y" or "YS" in pandas-related code since those are not supported in older versions of pandas.

We can discuss whether I should have done something differently there—I agree the deprecation warnings look annoying / concerning—but that is a separate issue (since we test against old versions of pandas it was awkward to address those deprecation warnings at the time).

I hope that extra context gives you some room for empathy 🙏. I'm trying to stay on top of these issues, but this one was particularly difficult to be out ahead of.

[max-sixty]

I hope that extra context gives you some room for empathy 🙏. I'm trying to stay on top of these issues, but this one was particularly difficult to be out ahead of.

Sorry, of course @spencerkclark . I didn't mean to sound too harsh. The impact is only on developers, not on users, so it's bounded.

FWIW I really wish we had a way of upgrading dependencies deliberately — e.g. dependabot supported conda — then we could be much more relaxed about this — when things broke we'd have a single new PR that failed, rather than every single PR failing...

---

I rechecked and see that the deprecation warnings from cftime we've been getting (e.g. ~20 in https://github.com/pydata/xarray/actions/runs/7410777266/job/20163815985) are indeed unrelated to this break! I had presumed they were the same.

---

Do you mind if I ask about how we managed the change? These days I'm a minor contributor, and you know this much better — I'm really not trying to give anyone a hard time.

The .infer_freq change is indeed quite unfriendly. But is it correct to think that if we'd responded to the deprecation warnings by allowing YE-FEB to work, then once .infer_freq returned YE-FEB, xarray would have handled this OK?

(I think I commented in a previous issue — could we even just pass anything we don't recognize through to pandas and then avoid maintaining a full list? Or we do need to intercept everything and so that's not viable...)

[spencerkclark]

All good @max-sixty, no worries!

But is it correct to think that if we'd responded to the deprecation warnings by allowing YE-FEB to work, then once .infer_freq returned YE-FEB, xarray would have handled this OK?

The main issue is that I, and I'm guessing @mathause, was not aware of this deprecation / change until three days ago. Looking back, this was discussed in pandas-dev/pandas#54275, but it had only been partially completed at the time of #8415 (the "A" was changed to "Y" but not all the way to "YE" yet). I had only looked at pandas-dev/pandas#55252, which was the initial PR going from "A" to "Y", and regrettably not the issue, and didn't realize there was to be a second PR changing "Y" to "YE" coming later on, pandas-dev/pandas#55792.

The deprecation warnings only showed up in the development version of pandas (i.e. what is now released as 2.2.0), so they were unfortunately not very visible.

---

FWIW I really wish we had a way of upgrading dependencies deliberately — e.g. dependabot supported conda — then we could be much more relaxed about this — when things broke we'd have a single new PR that failed, rather than every single PR failing...

Indeed this would be nice!

[max-sixty]

The main issue is that I, and I'm guessing @\mathause, was not aware of this deprecation / change until three days ago.

Yes, that makes sense. I hadn't realized that the warnings I'd been seeing over the past few months weren't directly related to the break.

Thanks a lot @spencerkclark

[mathause]

Thanks everyone and sorry about the delay - I was offline over the weekend. The failing tests should be covered elsewhere, so I'll merge.

[spencerkclark]

Awesome, thanks for the quick updates and merge @mathause!

[max-sixty]

Thanks @mathause !