Bug #89914
closed
Native date (TCA dbType) fields are not properly copied or localized
100%
Description
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:
'type' => 'input', 'eval' => 'date', 'dbType' => 'date',
How to reproduce:
- Create such a new record (or use an existing one)
- Copy it
- Paste it
Expected result:
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
Actual result:
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
What happens / the problem:
- The value "2019-12-11" is parsed in the local timezone 2019-12-11(T00:00:00+01:00) and converted to an timestamp (1576018800)
https://github.com/TYPO3/TYPO3.CMS/blob/b90897db1d13e3078609f1e66c4c91d2df465570/typo3/sysext/core/Classes/DataHandling/DataHandler.php#L1684
- The timestamp is now formatted as an UTC date (with gmdate) at 2019-12-10(T23:00:00+00:00)
https://github.com/TYPO3/TYPO3.CMS/blob/b90897db1d13e3078609f1e66c4c91d2df465570/typo3/sysext/core/Classes/DataHandling/DataHandler.php#L1740
Updated by Susanne Moog over 4 years ago
- Category set to DataHandler aka TCEmain
Updated by Wolfgang Klinger about 4 years ago
I can confirm this with TYPO3 10.4 too (had the same problem now),
There's a comment above this line
// We store UTC timestamps in the database, which is what getTimestamp() returns.
but then the DateTime is created without specifying the UTC timezone ;-)
The patch fixes this issue:
--- Classes/DataHandling/DataHandler.php.bak 2020-11-16 18:09:28.000000000 +0100
+++ Classes/DataHandling/DataHandler.php 2020-11-16 18:09:55.000000000 +0100
@@ -15,6 +15,7 @@
namespace TYPO3\CMS\Core\DataHandling;
+use DateTimeZone;
use Doctrine\DBAL\DBALException;
use Doctrine\DBAL\Driver\Statement;
use Doctrine\DBAL\Platforms\PostgreSqlPlatform;
@@ -1869,7 +1870,7 @@
// Convert the date/time into a timestamp for the sake of the checks
$emptyValue = $dateTimeFormats[$tcaFieldConf['dbType']]['empty'];
// We store UTC timestamps in the database, which is what getTimestamp() returns.
- $dateTime = new \DateTime($value);
+ $dateTime = new \DateTime($value, new DateTimeZone('UTC'));
$value = $value === $emptyValue ? null : $dateTime->getTimestamp();
}
}
Updated by Imko Schumacher about 4 years ago
- Copied from Bug #79925: Native date/datetime (TCA dbType) fields are not properly copied or localized added
Updated by Imko Schumacher about 4 years ago
- Related to Bug #91838: TCA l10n_mode="exclude" with TCA config dbType='datetime' set wrong timezone in translated records added
Updated by Imko Schumacher about 4 years ago
- Description updated (diff)
Add note about server timezone, needs to be a positive offset from UTC (e.g. Europe/Berlin).
Updated by Gerrit Code Review about 4 years ago
- Status changed from New to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/66670
Updated by Imko Schumacher about 4 years ago
- Description updated (diff)
- TYPO3 Version changed from 9 to 10
- PHP Version changed from 7.2 to 7.3
Updated by Markus Klein about 4 years ago
Wolfgang Klinger wrote in #note-2:
// We store UTC timestamps in the database, which is what getTimestamp() returns.
but then the DateTime is created without specifying the UTC timezone ;-)
This refers to the fact that a \DateTime uses the configured timezone and a unix timestamp is in UTC by definition.
So a new \DateTime('1.1.1970 01:00') in timezone MEZ will yield 0 for getTimestamp().
That is what the comment actually tries to convey.
Updated by Gerrit Code Review about 4 years ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/66670
Updated by Gerrit Code Review about 4 years ago
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/66670
Updated by Gerrit Code Review about 4 years ago
Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/66670
Updated by Gerrit Code Review about 4 years ago
Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/66670
Updated by Gerrit Code Review almost 4 years ago
Patch set 6 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/66670
Updated by Gerrit Code Review almost 4 years ago
Patch set 1 for branch 10.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/67200
Updated by Gerrit Code Review almost 4 years ago
Patch set 1 for branch 9.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/67201
Updated by Imko Schumacher almost 4 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 89f2e9f8f471fb58c2076a9b8fdcea1755342bab.
Updated by Benni Mack almost 4 years ago
- Status changed from Resolved to Closed