🤖 KI-Antwort des Forumsboten · automatisch erstellt und von einer zweiten KI gegengeprüft, ohne Gewähr.
Ja, dafür hat External Import die Transformation userFunction (in External Import 4.x heißt sie noch userFunc, die Parameter stehen dort unter params statt parameters). Ein eval gibt es als Transformation nicht.
Statt pauschal 2 Stunden zu addieren (im Winter wäre es nur 1 Stunde), solltest du den Wert ausdrücklich als UTC einlesen. Das Problem entsteht meist, weil der Datums-String ohne Zeitzone kommt und PHP ihn dann in der Zeitzone des Servers interpretiert. TYPO3 speichert einen Unix-Timestamp; wenn der stimmt, rechnet die Ausgabe automatisch in die lokale Zeit um.
TCA:
$GLOBALS['TCA'][$table]['columns']['startdate']['external'] = [
0 => [
'field' => 'published_at',
'transformations' => [
10 => [
// bei External Import 4.x: 'userFunc'
'userFunction' => [
'class' => \Vendor\Sitepackage\ExternalImport\DateTransformation::class,
'method' => 'parseUtcDate',
],
],
],
],
];
Die Klasse in deiner Extension (per Autoload erreichbar):
<?php
namespace Vendor\Sitepackage\ExternalImport;
class DateTransformation
{
public function parseUtcDate($record, $index, $params)
{
$value = trim((string)$record[$index]);
if ($value === '') {
return 0;
}
$date = new \DateTime($value, new \DateTimeZone('UTC'));
return $date->getTimestamp();
}
}
External Import ruft die Methode mit dem kompletten Datensatz, dem Feldnamen und den Parametern auf und schreibt den Rückgabewert ins Feld. Enthält der String schon eine Zeitzone (z. B. Z oder +00:00), verwendet PHP diese, das Ergebnis bleibt also richtig.
Falls der gespeicherte Timestamp bereits stimmt und nur die Anzeige 2 Stunden daneben liegt, ist die Zeitzone des Servers das Problem. Dann in der LocalConfiguration.php setzen:
$GLOBALS['TYPO3_CONF_VARS']['SYS']['phpTimeZone'] = 'Europe/Berlin';
Doku zu den Transformationen: https://docs.typo3.org/p/cobweb/external_import/5.1/en-us/Administration/Transformations/Index.html