Bug #35369

DateTimeConverter's timezone key leads to unexpected behavior

Added by Adrian Föder over 9 years ago. Updated over 8 years ago.

Must have
Start date:
Due date:
% Done:


Estimated time:
(Total: 0.00 h)
PHP Version:
Has patch:


The doc comment of the DateTimeConverter says

/** [...]
 * By using an array as source you can also override time and timezone of the created DateTime object:
 * array(
 *  'date' => '<dateString>',
 *  'hour' => '<hour>', // integer
 *  'minute' => '<minute>', // integer
 *  'seconds' => '<seconds>', // integer
 *  'timezone' => '<timezone>', // string, see http://www.php.net/manual/timezones.php
 * );

If the timezone is set (given), \DateTime::setTimezone() is called on the already-created object.

But this method modifies the resulting date and time representation. Currently, the DateTime object is created via

$date = \DateTime::createFromFormat($dateFormat, $dateAsString);

So, if the user provided e.g. 15:04:23 and timezone EST (even compare to the html sample @ #27417), the following might happen:

  1. \DateTime::createFromFormat() creates a date representing 15:04:23 CET, because the server's default timezone is CET (e.g.),
  2. timezone EST is set from the source, so ->setTimezone() is invoked, resulting in modifying the \DateTime object into 11:04:23 EST
  3. but the intended target date should be 15:04:23 EST (compare again the example @ #27417).

My suggestion would be a breaking change that throws overrideTimezoneIfSpecified() away and finds the correct timezone at the

$date = \DateTime::createFromFormat($dateFormat, $dateAsString);

line. The third argument would then be the time zone.

an additional way could be a workaround that finds out the difference between the current and the intended timezone, applies ->setTimezone() and then ->modify()s the DateTime object with that difference period.


Related issues

Related to TYPO3.Flow - Feature #27417: DateTime conversion supportResolvedBastian Waidelich2011-06-14


Also available in: Atom PDF