Bug #89914
Updated by Imko Schumacher over 3 years ago
This bug was already reported by Ludwig Rafelsberger for TYPO3 7 (#79925). But the bug was closed without resolution. I just stumpled upon this behavior in TYPO3 v9.5.11
When you use a native DATE-field, translated or copied records will be off-by-one day
Prerequisites:
* (Server) timezone with positive offset (e.g. Europe/Berlin)
TCA:
<pre>
'type' => 'input',
'eval' => 'date',
'dbType' => 'date',
</pre>
How to reproduce:
* Create such a new record (or use an existing one)
* Copy it
* Paste it
Expected result:
<pre>
select * from tx_example_domain_model_event;
uid pid some_int_based_tstamp some_native_dbtype_field
1 1 1487548800 2019-12-11
2 1 1487548800 2019-12-11 <-- the copied record as it should be
</pre>
Actual result:
<pre>
select * from tx_example_domain_model_event;
uid pid some_int_based_tstamp some_native_dbtype_field
1 1 1487548800 2019-12-11
2 1 1487548800 2019-12-10 <-- the copied record with wrong date
</pre>
If it's a translation and you open the original record and save it again, the date of the translation will get adjusted, if it's l10n_mode=exclude.
As far as I can see, the problem is that the date is first converted from "2019-12-11" to a unix-timestamp:
https://github.com/TYPO3/TYPO3.CMS/blob/ba5a118594e0d0b4afb4f66f336ef9ad3074da02/typo3/sysext/core/Classes/DataHandling/DataHandler.php#L1770
Then it's converted back to a date, but using gmdate instead of date:
https://github.com/TYPO3/TYPO3.CMS/blob/ba5a118594e0d0b4afb4f66f336ef9ad3074da02/typo3/sysext/core/Classes/DataHandling/DataHandler.php#L1826