fix: validate February 29th in date assertion when format lacks a year

[deeferentleeg]

Summary

Fixes #336.

The date() assertion uses DateTime::createFromFormat('!'.$format, $value), where the ! modifier resets all unspecified fields to the Unix epoch (1970-01-01 00:00:00 UTC). Because 1970 is not a leap year, valid dates such as 29/02 with format d/m are incorrectly rejected — there is no February 29th in 1970.

The fix

When the initial !-based parse fails and the format does not contain a year specifier (Y, y, or o), the assertion now retries by prepending a known leap year (2000) to both the value and the format:

$dateTime = DateTime::createFromFormat('!Y '.$format, '2000 '.$value);

The round-trip check ($value !== $dateTime->format($format)) is then performed against the original format, so the prepended year does not appear in the comparison. This makes the fix fully deterministic — it does not depend on the current system year.

Behavior preserved

• Formats with a year (e.g. Y-m-d) are unaffected — the retry only triggers when no year token is present.
• 2011-02-29 with Y-m-d is still correctly rejected (2011 is not a leap year).
• Overflow dates like 32/01 with d/m are still rejected by the round-trip check.
• 30/02 with d/m is still rejected (February 30th does not exist in any year, including 2000).

Tests

• Added ['29/02', 'd/m'] to validDateProvider — February 29th without a year should now pass.
• Added ['30/02', 'd/m'] to invalidDateProvider — February 30th without a year should still fail.

---

AI usage disclosure: An AI assistant was used to help locate the relevant code and draft this change. I have reviewed and understand every line of the diff, and I am the sole author of this contribution.