Epic #77562: Misbehaviors with datetime values and timezones
Extbase mapping of \DateTime for integer values does not set timezone with region string but only offset
Currently the extbase DataMapper handles the conversion of integer values to \DateTime
return \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance($targetType, date('c', $value));
Therefore the value itself will be correct but the timezone will be e.g. "+01:00" or similar instead of e.g. "Europe/Vienna".
That means it will be fine as long as one doesn't modify the date.
For instance, a date like March 20th 00:00:00 with \DateTimeZone "+01:00" when calling $date->modify('+1 month')
if one were to use "Europe/Vienna" the date would switch to daylight savings time.
How the result with the \DateTimeZone "+01:00" then the result will be April 20th 00:00:00 with \DateTimeZone "+01:00" which means the \DateTimeZone is wrong as with daylight savings time it would actually be "+02:00".
This means a comparison of a date in the correct timezone to the calculated one might fail or be of by the difference between daylight saving time and normal time.
However, if the \DateTimeZone is the regional \DateTimeZone like e.g. "Europe/Vienna" this will work correctly.
The easiest solution is probably to add $date->setTimezone prior to return the \DateTime.
#4 Updated by Paul Golmann about 2 years ago
I found myself with the same problem. I've created a patch (see below for explanation).
The problem is, as far as I can see:
creates a string representing the date/datetime including the timezone, which is what we want. But the string representation (ISO 8601) encodes the timezone as a offset (e.g.
2017-10-20T00:00:00+02:00if the local server time (SYS['phpTimeZone']) is set to
Berlin/Europe). That leads the resulting \DateTime to only have the offset but not the timezone region. That means when "working" on the DateTime information about e.g. the summer time/daytime saving gets lost. For me that caused shifting of dates around the (german) summer time change in October this year using a calendarize configuration with a frequency.
In the patch I've aligned the code for mapping timestamps with that of datetime database fields. That means that the timezone will correctly be set as
Europe/Berlin instead of