I think the test here is that the contour x and/or y axes are datetimes, and that the manual placement of clabels can be specified with datetimes. I'm actually skeptical that this works, but if not, would be good to document it.

How would I be able to test this? I've tried a few different things but only ran into errors.

Edit: Perhaps this PR should be modified to just delete the test? I don't think what#26864 is attempting to test makes sense for clabel.

@AliAboelela123 I've not looked in detail, but it is possible to contour withx ory as a datetime vector.z should just be normal non-datetime data. First, it would be madly useful to double check thatclabel works at all for that case. Second,clabel takes amanual kwarg, and the x, y version of that kwarg would ideally take datetime as thex value. I'm not sure if it does or not.

https://matplotlib.org/stable/api/contour_api.html#matplotlib.contour.ContourLabeler.clabel

One use-case for z datetimes is to plot amap of monsoon onset, though I agree that having datetimes on the x- or y-axis (e.g.Hovmöller diagrams) is more common. Perhaps it is worth testing both?

I've tried a few different things but only ran into errors.

If the errors show that we don't currently support this, then that is useful information and part of what the issue is looking to find out. So please post your findings 👍

I've made some updates, I don't expect this to be merged soon but rather just trying to continue the conversation. I summarized my findings in an edit

@AliAboelela123 I still think you are misunderstanding. The x array should be datetimebefore sending to contour. Subsequently clabel should be called with the manual kwarg.

Perhaps it is worth testing both

The z data in contour is not run through unit machinery, so all we would be testing is that clabel takes an arbitrary string.

Ok I've tried to fix the PR by constructing the contour using datetime objects and passing that as input to the clabel function. I have not used the manual kwarg though. Do the current changes more accurately reflect what this test suite is attempting to test?

Subsequently clabel should be called with the manual kwarg.

I have not used the manual kwarg though. Do the current changes more accurately reflect what this test suite is attempting to test?

No? What are you not understanding about the "manual" kwarg?

# Select specific x valuesselected_x_values = [x[0], x[6], x[12], x[18]]#Pair them with specific datesselected_dates = [dates[0], dates[3], dates[6], dates[9]]#Create pairs of (x, date)manual = [(x_val, date) for x_val, date in zip(selected_x_values, selected_dates)

I tried to pass the above ^^ "manual" param to the clabel function but I get the following error:

"TypeError: Cannot cast array data from dtype('O') to dtype('float64') according to the rule 'safe'"

This makes me think that the manual param expects the tuples to have float type i.e. coordinates in a plane rather than data type 'O' which I think means object and is referencing the datetime obj. I'm not sure if I'm doing something wrong or if this is the intended limitation of the clabel function which we are attempting to document.

I didn't test it myself, but if the manual clabel doesn't work then that would be a bug report issue. Probably we should process the unit info for the clabel manual inputs.

This PR could still test that labelling works when the x and y axis are datetimes. Somewhat more trivial, but worth checking.

I've opened#27525 for themanual argument ofclabel not accepting units. This PR is possibly okay without testing that yet, but it currently has linting issues that need to be fixed.