PHP8 + MAX aggregation in Views on Date fields throw error

+++ docroot/core/modules/views/src/Plugin/views/field/NumericField.php
@@ -169,6 +169,12 @@
+        $value = date("Y",strtotime($value));

I think you need to cast date result into int: $value = (int) date("Y",strtotime($value));
But that might work only for you because others could have a different date format and separator like "/".

+++ docroot/core/modules/views/src/Plugin/views/field/NumericField.php
@@ -169,6 +169,12 @@
     $value = round($value, $precision);

I would say that it is safe to do casting here instead of creating a new condition because it is exactly what PHP 7 did before and let's follow old code behaviour here.
$value = round((int) $value, $precision);

Tests failed due to code quality checks failed.

fix cs error #2. Please review it

Let's trigger tests

#7 seems to work for me, at least where 'year' is being used.
PHP 8 & MySQL 5.7

Just a minor change to date-string check condition, for better coverage.

Moving back to NW for a test.

I would leave here an alternative fix for date cases like "2021/2022"

This would work too.
I would suggest something like:

if (is_string($value)) {
  $value = (int) $value;
}

else we are ignoring $precision completely.

Then it might looks like

if (is_string($value)) {
  if (strtotime($value) !== FALSE) {
    $value = date("Y", strtotime($value));
  }
  else {
    $value = (int) $value;
  }
}

Actually, it would be easier to mimic how PHP v7.x handled it.
After doing some tests, it seems a simple type cast should be sufficient.
So as not to handle the string with any assumptions and in a more generalized way.

if (is_string($value)) {
  $value = (float) $value;
}

Attaching the effective patch.

Just some thoughts: Since this is a render/display utility function, there could be a more agreed-upon way to display a string, passed through an aggregating function.

Re-rolled patch for Drupal 9.5.x

I tested patch #18 on Drupal 9.4.6 and php 8.1 and it worked for me -- though my issue was related to a text field rather than date field. Same error message, though.

This still needs a test case

Also would be helpful to have steps to reproduce this issue.

I added steps to create a view that triggers the error and is fixed with this patch.

There are two very different approaches in the patches here.

#11 has:

+    if (is_string($value)) {
+      if (strtotime($value) !== FALSE) {
+        $value = date("Y", strtotime($value));
+      }
+    }

This will convert date strings to year.

#18 has:

+    if (is_string($value)) {
+      $value = (float) $value;
+    }

This will convert a date string to to a number like 2025.0.

A patch in #3338895 has:

+    $value = round((float) $value, $precision);

Basically the same as #18, without the check for a string.

I bundled them all together and came up with this:

    if (is_string($value)) {
      if (strtotime($value) !== FALSE) {
        $value = date("U", strtotime($value));
      }
    }

    $value = round((float) $value, $precision);

Now a date string is converted to a timestamp. However, I'm not sure if this does anything for the max comparison, or if this just rendering the value afterwards.