This commit also makes some changes in how the `DateTime` rule behaves,
by not accepting `DateTimeInterface` as valid when a format is given.
Also:
- Create `DateTimeHelper` to eliminate some code duplication;
- Create integration tests for `DateTime` rule;
- Rename "format" placeholder to "sample" in the message;
- Update documentation of "DateTime" rule.
The `DateTime::createFromFormat()` tries to guess the date too much and
sometimes wrong parsing may happen:
```php
echo DateTime::createFromFormat('Ym', '202309')->format('Ym');
```
The output of the above code is "202310", not "202309".
Using `date_parse_from_format()` we get a more precise parsing.
timezone information. However, in the comparison the DateTime-object is
first output to a timestamp, which is then converted to a string with the
date()-function. But because a timestamp does not include timezone
information, date() will assume the system's timezone. So if the system
timezone set in the PHP settings is UTC, a string with another timezone,
e.g. 2015-04-24T21:11:00+02:00, will fail to be validated. The result from
the date()-function in this example is 2015-04-24T19:11:00+00:00, which is
a different string then the input.
The DateTime-class has also an option to create a string from a format,
DateTime->format(). So it is possible to skip the use of the
date()-function with the added benefit that using format() does have
access to the timezone information and thus produces the expected
2015-04-24T21:11:00+02:00 to compare with the given input.
This commit changes the Rule to accommodate this and expands the tests. If
these added tests are run before applying the fix to the Date-rule, the
tests will fail.
