PR Summary

Closes #24951

Certainly needs tests/docs prior to merge, but opening to further the conversation.

This introduces a method to Converters to validate that a given formatter works with with the Converter.

Currently it is implemented as a staticmethod which returns a bool and then matplotlib warns if that bool is false.
One option that I would consider would be to push the warning into the method, which could then suggest the valid types with a more targetted error message.

I chose a method so that more complicated logic could be used, but so far all instances I have implemented or considered do simple isinstance checks.
One alternative if this was sufficient would be to make the thing that gets propegated a list (tuple?) of Formatter classes and then do the isinstance check directly rather than calling the method.
This could potentially also have APIs for registering formatters as valid for a given converter (or just be directly mutable as a list).
The cost, though is that you are limited to only isinstance checks there.
(Of course with the method implementation, individual classes are free to implement such registration APIs, but lacks standardization)

If the converter is not set, it does not get checked.
Default behavior of ConversionInterface (and any subclasses which do not override the method) is to accept any formatter (i.e. return True indiscriminantly).
Thus except where downstream inherits from DateConverter or StrCategoryConverter it is entirely opt-in to this additional check.
Converters that expect essentially just float values (and should work with many different formatters that are not all enumerated) retain default behavior (internally, the example is DecimalConverter).
It is only a warning, not an error, mostly to ensure that if the list is wrong, you can still do what you want.

One slight wrinkle that is perhaps slightly awkward is that the NullFormatter does need to return True as that occurs during some setup/initialization phases (as well as just the semantics that you should be able to use NullFormatter to disable labels anyway)

@spencerkclark I am particularly interested in your opinion here
Here is the appropriate diff for nc-time-axis that I tested with:

diff --git a/nc_time_axis/__init__.py b/nc_time_axis/__init__.py
index a5276ad..76c4d74 100644
--- a/nc_time_axis/__init__.py
+++ b/nc_time_axis/__init__.py
@@ -582,6 +582,12 @@ class NetCDFTimeConverter(mdates.DateConverter):
 
         return result
 
+    @staticmethod
+    def validate_formatter(formatter):
+        return isinstance(formatter, (mticker.NullFormatter,
+                                      AutoCFTimeFormatter,
+                                      CFTimeFormatter))
+
 
 def is_numlike(x):
     """

The growing pain here is that without the above change, the NetCDFTimeConverter class from cftime will warn for the correct formatters and not the mpl-default date formatters (that don't work properly).
This is because of the mdates.DateConverter inheritance that is not overridden without the above diff. As such, not sure there is any path that doesn't inherit the incorrect behavior without a change in nc-time-axis.

Since this affects downstream with warnings (not direct errors, at least), I would like to consult with at least the likes of Pandas (xarray's converting/formatting support is largely via nc-time-axis, above).
If there are other downstream projects we should consult with, happy to hear more.

I do not (yet) affirmatively test that the warning is issued, though it did fail a test which sets FixedFormatter on a date axis and already ignores a warning against using such without FixedLocator.

Questions:

• Is the information sufficient to make determinations?
  • Would a classmethod be better, or is an instance method necessary? (considering all other functionality of ConversionInterface is staticmethod, that is where I started)
• Would list of types be easier to manage, even if it limits flexibility?
• is checking in set_formatter both sufficient and not overzealous?
  • What about if the converter is changed? should we ensure warning then?
  • What if you want to change both, can it be done without either warning or setting to None?

PR Checklist

Documentation and Tests

• Has pytest style unit tests (and pytest passes)
• Documentation is sphinx and numpydoc compliant (the docs should build without error).
• New plotting related features are documented with examples.

Release Notes

• New features are marked with a .. versionadded:: directive in the docstring and documented in doc/users/next_whats_new/
• API changes are marked with a .. versionchanged:: directive in the docstring and documented in doc/api/next_api_changes/
• Release notes conform with instructions in next_whats_new/README.rst or next_api_changes/README.rst