The timestamp must be numeric

Tried to reproduce the issue getting the same error (The timestamp must be numeric.) while working with D10 and webform 6.2.0-beta6 .
However when i tried to reproduce the same in D9 and with webform 6.1.4 though we are able to save the webform fields and condition without any error . however we are not getting the desired result .

Follow the same steps as mentioned in the issue with D9 and webform 6.1.4 , Set the page2 date field min value to date1 field value using (([webform_submission:values:date1_field_name]) . Now when we try to submit the response , the date validation for date2 is checking min value against the submission date of webform(today) instead of the date1 field value which is not the ideal behaviour.

Adding the screenshot for the same.

So the below YAML source when pasted into a D10 6.2.x webform trigger the error

page_01:
  '#type': wizard_page
  '#title': page_01
  date_01:
    '#type': date
    '#title': date_01
page_02:
  '#type': wizard_page
  '#title': page_02
  date_02:
    '#type': date
    '#title': date_02
    '#date_date_min': '[webform_submission:values:date_01]'

I was not able to track down the root cause of the regression but the attached patch is reasonable and safe fix to immediate issue and is unlikely to cause additional regressions.

@jrockowitz i tried to applied the patch(#7) , after applying the patch although we are successfully able to save webform with the conditions on the date field , however we are still getting same error now upon submission of the webform. Attaching the screenshot for reference .

The error is originating from \Drupal\Component\Datetime\DateTimePlus::createFromTimestamp

A slightly better approach where all invalid element date properties will unset. This approach can be used to prevent other date-related regressions.

This patch should also be applied to 6.1.x

The patch will stop the "timestamp must be numeric" errors. But is this field supposed to be able to support tokens? Should it set an error message when it encounters an invalid value in one of the four properties that it checks?

The tokens are replaced via parent::prepare($element, $webform_submission).

If the tokens are NOT replaced, they are invalid, so they should be removed.

OK, so you're saying that any valid tokens will have already been replaced? That makes sense. In that case, this patch makes sense to me.

Automatically closed - issue fixed for 2 weeks with no activity.