Error when try to validate date format when date_default_timezone_set is set for some specific timezones.

[alustau]

Laravel Version

12.*

PHP Version

8.4.*

Database Driver & Version

No response

Description

date_format:Y-m-d H:i:s fails for datetimes that fall into DST transitions when the app timezone (or date_default_timezone_set) is set to a DST-observing zone (e.g. Europe/Amsterdam, Europe/London, Europe/Athens).

During DST start, certain local times are non-existent (e.g. in Amsterdam on 2025-03-30, 02:00:00 → 02:59:59 does not exist). The validator appears to parse and normalize the input using the current timezone, so DateTime::createFromFormat('!Y-m-d H:i:s', '2025-03-30 02:00:00') becomes 2025-03-30 03:00:00 (normalized), which then fails the strict equality check in the validation rule—even though the input string matches the declared format exactly.

In short: DST normalization changes the parsed time and the rule reports the format as invalid.

Steps To Reproduce

1- Set the PHP default timezone to a DST zone (Amsterdam shown here).
2- Validate a string that matches Y-m-d H:i:s and falls in the DST “gap”.

<?php

use Illuminate\Support\Facades\Validator;

date_default_timezone_set('Europe/Amsterdam');

$payload = ['ts' => '2025-03-30 02:00:00']; // Local time that doesn't exist due to DST shift (+1h)
$rules   = ['ts' => 'date_format:Y-m-d H:i:s'];

$validator = Validator::make($payload, $rules);

var_dump($validator->passes()); // false
var_dump($validator->errors()->all());
// ["The ts does not match the format Y-m-d H:i:s."]

Script to find which date will fail:

<?php
date_default_timezone_set('Europe/Amsterdam');

$year = 2025;

for ($month = 1; $month <= 12; $month++) {
    $daysInMonth = match ($month) {
        1, 3, 5, 7, 8, 10, 12 => 31,
        4, 6, 9, 11 => 30,
        2 => 28,
        default => throw new Exception("Invalid month: $month"),
    };

    for ($day = 1; $day <= $daysInMonth; $day++) {
        for ($hour = 0; $hour < 24; $hour++) {
            
            $date = sprintf("$year-%02d-%02d %02d:00:00", $month, $day, $hour);

            $dateFormated = DateTime::createFromFormat('!Y-m-d H:i:s', $date)->format('Y-m-d H:i:s');

            if ($dateFormated !== $date) {
                echo "Date that will thrown exception: $dateFormated !== $date\n";
            }
        }
    }
}

Additional Context

Timezones which breaks is when it has a summer time and it's +x

[macropay-solutions]

@alustau

    public function validateDateFormat($attribute, $value, $parameters)
    {
        $this->requireParameterCount(1, $parameters, 'date_format');

        if (!is_string($value) && !is_numeric($value)) {
            return false;
        }

        foreach ($parameters as $format) {
            try {
                $date = DateTime::createFromFormat('!' . $format, $value);

                if ($date && $date->format($format) == $value) { // do you think it is safe to replace this with $date instanceof DateTime ?
                    return true;
                }
            } catch (ValueError) {
                return false;
            }
        }

        return false;
    }

Could this be related to how DateTime::createFromFormat interprets the date string (that does not have timezone in it) as UTC or local without DST and then on formating it it applies the DST. In this case this is an issue for php.

[alustau]

I saw this code to be able to understand what was happening on my problem, but I am not sure if it's a PHP issue. In theory this hour does not exist. I created this issue here to see what the community would say about this, or at least help me to figure out a good solution. Thanks anyway

[macropay-solutions]

Now we got the whole picture. because 2 AM becomes 3 AM, the interval from 2 to 3 AM does not exist and the DateTime::createFromFormat knows about it and it formats the date accordingly.

The only issue here is that the input data is invalid because that time does not exist in that timezone.
@alustau why do you see this as a bug? If the date string does not contain a timezone in it, it is normal for the DateTime to see it as local time.

[alustau]

@macropay-solutions because I'm validating if the string has a valid date format. This situation I'm passing a valid date format...

[macropay-solutions]

More interesting is the + 6 months change for DST when 3 AM becomes 2 AM resulting in multiple 2 equal date time strings that point to 2 different moments in time.

2025-09-30 02:10:10 ..... 2025-09-30 02:59:59|2025-09-30 02:00:00...2025-09-30 02:10:10

This is why we always store date times in UTC and if needed we format them to local only when they need to be displayed.

[macropay-solutions]

@macropay-solutions because I'm validating if the string has a valid date format. This situation I'm passing a valid date format...

As per docs

date_format:format,...
The field under validation must match one of the given formats. You should use either date or date_format when validating a field, not both. This validation rule supports all formats supported by PHP's DateTime class.

For convenience, date-based rules may be constructed using the fluent date rule builder:

use Illuminate\Validation\Rule;

'start_date' => [
'required',
Rule::date()->format('Y-m-d'),
],

date_format implies valid date

[alustau]

I'm using timestamp as date column on mysql database, and I am setting the connection to use the user's timezone. Which in this case it would save in UTC, no?

[macropay-solutions]

From the internet for mysql https://medium.com/@kenny_7143/time-zone-in-mysql-e7b73c70fd4e

The TIMESTAMP data type stores values in UTC internally and automatically converts them to the current session's time zone upon retrieval.