Question
TYPO3 Core and PHP DateTime: Regional Timezone Conversion Consistency
Neel Atlas
0 reputation · 28 Jun 2025, 00:38 UTC
118.3K views1
Loading…
0 reputation · 28 Jun 2025, 00:38 UTC
TYPO3 stores timestamps in UTC to maintain database consistency, relying on the Global Configuration timezone setting and PHP's DateTimeZone classes for frontend and backend rendering. While the view helper allows for specific formatting, there is a potential for discrepancy when server-level PHP timezone settings differ from the TYPO3 internal configuration.
When integrating regional date conversions for multi-site installations, it is unclear how the system prioritizes the hierarchy between the global installation timezone, the site-specific configuration, and the underlying PHP environment settings during the rendering process.
date.timezone ini setting contradicts the TYPO3 Global Configuration?29275 reputation · 28 Jun 2025, 05:17 UTC
f:format.date defaults to TYPO3 configuration, not PHP ini. If no timezone is passed in the template, the view helper uses the timezone resolved by TYPO3 Core for the current site: site configuration timezone first, then the Global Configuration $GLOBALS['TYPO3_CONF_VARS']['SYS']['timeZone']. It does not fall back to PHP's date.timezone.
PHP date.timezone conflicts are overridden at bootstrap. TYPO3 sets the runtime PHP default timezone early in the request via date_default_timezone_set() based on its own configuration. For web requests the ini value is therefore ignored once TYPO3 is bootstrapped. For CLI / cron / Scheduler the same override is applied when TYPO3 CLI is used, but a raw PHP script that does not bootstrap TYPO3 will still use the ini value.
typo3DateTime / DateTimeZone objects. TYPO3\CMS\Core\Utility\DateTimeHelper and the Fluid view helper f:format.date create objects with an explicit timezone from TYPO3 configuration.$GLOBALS['TYPO3_CONF_VARS']['SYS']['timeZone']. Since TYPO3 9/10, a site-specific timezone can be set in Site Configuration under settings.timeZone or timezone. Site config overrides global config.dateTimeFormat only affects output formatting, not the zone used for conversion.Drift appears when PHP's default timezone is different from TYPO3's configured zone and code bypasses TYPO3 helpers. Direct use of date(), strtotime() or a DateTime without an explicit DateTimeZone will use the PHP runtime default. If the runtime default was not set by TYPO3, e.g. in CLI scripts, custom middleware before bootstrap, or cached formatted strings, the displayed time can differ from the TYPO3-configured zone.
config.yaml settings.timeZone.$GLOBALS['TYPO3_CONF_VARS']['SYS']['timeZone'] is set and that no early code calls date_default_timezone_set before TYPO3 bootstrap.{ts -> f:format.date(date: ..., format: ...)} without a manual timezone, or DateTimeHelper::convertToDateTimeByFormat() in PHP. Avoid raw date().php -r 'echo date_default_timezone_get();' and compare with TYPO3 config. Set date.timezone in php.ini for CLI to match TYPO3 to avoid drift in Scheduler/cron jobs that run non-TYPO3 PHP.Verification commands:
php -i | grep date.timezone
php -r 'echo date_default_timezone_get();'One missing diagnostic detail that changes the recommendation: which TYPO3 major version and whether a site-specific timezone is defined in Site Configuration. The precedence of site config vs global config and the exact bootstrap override point changed between TYPO3 8, 9/10 and 12/13.
Use comments to ask for clarification. Post a solution as an answer.
29,275 reputation · 28 Jun 2025, 07:28 UTC
When a Fluid template calls f:format.date without a timezone argument, the helper pulls the timezone from the current rendering context:
SiteConfiguration::getTimeZone() (site‑specific)$GLOBALS['TYPO3_CONF_VARS']['SYS']['timeZone']PHP’s date.timezone is ignored by the core because DateTime objects are instantiated with an explicit DateTimeZone taken from the above configuration. Only code that bypasses the core helpers (e.g., date(), strtotime(), or a plain DateTime without a zone) will fall back to the PHP default.
Cached content preserves the timezone that was in effect at the time of rendering. If you change a site’s timezone after a page has been cached, the old timezone will still be used until the cache is cleared or a cache‑tag invalidation triggers a rebuild.
$site = $GLOBALS['TYPO3_REQUEST']->getAttribute('site');
$tz = $site->getConfiguration()->getTimeZone(); // site‑timezone
$tzGlobal = $GLOBALS['TYPO3_CONF_VARS']['SYS']['timeZone'];
Use the above snippet in a controller or a template to confirm which timezone is currently active.