Bug #35369

DateTimeConverter's timezone key leads to unexpected behavior

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

Status:
Resolved
Priority:
Must have
Category:
Property
Start date:
2012-12-25
Due date:
% Done:

100%

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

Description

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.


Subtasks


Related issues

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

Actions
#1

Updated by Bastian Waidelich over 9 years ago

  • Category changed from Validation to Object
  • Priority changed from Should have to Must have
  • Target version set to 1.1

Good catch! +1 for using the 3rd argument of DateTime::createFromFormat() to solve this. And we should add a unit test that reproduces the error.

#2

Updated by Karsten Dambekalns over 9 years ago

  • Target version changed from 1.1 to 1.1 RC1
#3

Updated by Karsten Dambekalns over 9 years ago

  • Category changed from Object to Property
  • Target version changed from 1.1 RC1 to 1.1
#4

Updated by Karsten Dambekalns over 9 years ago

  • Status changed from New to Accepted
  • Assignee set to Karsten Dambekalns
#5

Updated by Gerrit Code Review over 9 years ago

  • Status changed from Accepted to Under Review

Patch set 1 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/12737

#6

Updated by Gerrit Code Review over 9 years ago

Patch set 2 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/12737

#7

Updated by Gerrit Code Review over 9 years ago

Patch set 1 for branch FLOW3-1.1 has been pushed to the review server.
It is available at http://review.typo3.org/12770

#8

Updated by Karsten Dambekalns over 9 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
#9

Updated by Gerrit Code Review over 9 years ago

  • Status changed from Resolved to Under Review

Patch set 2 for branch FLOW3-1.1 has been pushed to the review server.
It is available at http://review.typo3.org/12770

#10

Updated by Karsten Dambekalns over 9 years ago

  • Status changed from Under Review to Resolved

Also available in: Atom PDF