Update test cases for the data provider used for the invalid date time tests.
Why?
This change is to ensure Respect\Validation is intentional about the DateTime formats.
For context the ISO 8601 standard says that we shouldn't accept -00:00 (or anything similar) offsets.
I noticed that there was an a change in how CanValidateDateTime.php behaved from v2.2 to v2.3.
Prior to v2.3 date time formats of 2018-01-30T19:04:35-00:00 (note the -00:00) would pass validation. After updating to v2.3 the format is not accepted.
This is because the DateTime::createFromFormat accepts the $value of 2018-01-30T19:04:35-00:00 but internally converts the -00:00 to +00:00
$formattedDate = DateTime::createFromFormat(
$format,
$value,
new DateTimeZone(date_default_timezone_get())
);
This in turn causes the validation around $value !== $formattedDate->format($format)) to fail
Since PHP internally converts the -00:00 to a +00:00, will Respect\Validation ever consider accepting a format of -00:00 (and other offshoots of the -0000 time offsets) 😄 ?
What?
Why?
This change is to ensure
Respect\Validation
is intentional about the DateTime formats.For context the ISO 8601 standard says that we shouldn't accept
-00:00
(or anything similar) offsets.I noticed that there was an a change in how
CanValidateDateTime.php
behaved from v2.2 to v2.3.Prior to v2.3 date time formats of
2018-01-30T19:04:35-00:00
(note the -00:00) would pass validation. After updating to v2.3 the format is not accepted.This is because the
DateTime::createFromFormat
accepts the$value
of2018-01-30T19:04:35-00:00
but internally converts the-00:00
to+00:00
This in turn causes the validation around
$value !== $formattedDate->format($format))
to failFollow up
Since PHP internally converts the
-00:00
to a+00:00
, will Respect\Validation ever consider accepting a format of-00:00
(and other offshoots of the-0000
time offsets) 😄 ?