---
title: "Breaking: #110414 - Remove global access time variables"
manual: "TYPO3 Core Changelog"
version: "main"
permalink: "https://docs.typo3.org/permalink/changelog:breaking-110414-1786380424"
source: "Changelog/15.0/Breaking-110414-RemoveGlobalAccessTimeVariables.rst"
modified: "2026-09-15T10:46:36+00:00"
---

# Breaking: #110414 - Remove global access time variables

See [forge#110414](https://forge.typo3.org/issues/110414)

## Description

The global variables `$GLOBALS['ACCESS_TIME']` and
`$GLOBALS['SIM_ACCESS_TIME']` have been removed.

Both were introduced in 2008 and held the current (respectively the simulated)
execution time floored to the full minute. Their only purpose was to keep the
SQL of `starttime` / `endtime` comparisons textually identical for up
to 60 seconds, so that the MySQL query cache could serve repeated requests. That
query cache has been removed from MySQL and is disabled by default in MariaDB,
so the original motivation no longer applies.

Beyond that, both values were pure derivatives of `$GLOBALS['EXEC_TIME']`
and `$GLOBALS['SIM_EXEC_TIME']` that had to be kept in sync manually, which
was an error-prone contract.

The minute granularity itself is kept, since record visibility and the frontend
cache lifetime derived from `starttime` / `endtime` must use the very
same clock. It now lives in the date aspect of the Context API, which gained two
typed methods:

-   `\TYPO3\CMS\Core\Context\DateTimeAspect::getTimestamp()`
-   `\TYPO3\CMS\Core\Context\DateTimeAspect::getTimestampWithMinutePrecision()`

The already existing property `$context->getPropertyFromAspect('date', 'accessTime')`
is unchanged and now delegates to the latter method.

As a consequence, `\TYPO3\CMS\Core\Database\Query\Restriction\StartTimeRestriction`
and `\TYPO3\CMS\Core\Database\Query\Restriction\EndTimeRestriction` fall back
to the date aspect instead of the global variable when no timestamp is handed in.
The `\RuntimeException` with codes `1462820645` and `1462821084`,
which was thrown when the global was missing, has become unreachable and has been
removed.

## Impact

Reading `$GLOBALS['ACCESS_TIME']` or `$GLOBALS['SIM_ACCESS_TIME']`
raises an "Undefined array key" warning and evaluates to `null`.

Writing to either variable no longer has any effect. In particular, simulating
another point in time by setting `$GLOBALS['SIM_ACCESS_TIME']` is silently
ignored, and records are then evaluated against the real current time.

The following constructors received an additional
`\TYPO3\CMS\Core\Context\Context` argument:

-   `\TYPO3\CMS\Frontend\Cache\CacheLifetimeCalculator`
-   `\TYPO3\CMS\Redirects\Service\RedirectService`
-   `\TYPO3\CMS\Backend\Controller\PageLayoutController`

## Affected installations

Installations with extensions that read or write one of the two global
variables, that rely on the removed exceptions of the start and end time
restrictions, or that instantiate one of the above classes manually instead of
using dependency injection.

## Migration

Use the date aspect of the Context API instead of the global variables:

```php
use TYPO3\CMS\Core\Context\Context;

// Before
$accessTime = $GLOBALS['SIM_ACCESS_TIME'];

// After, with dependency injection
public function __construct(private readonly Context $context) {}

$accessTime = $this->context->getAspect('date')->getTimestampWithMinutePrecision();
```

In places without dependency injection, the current context is fetched via
`GeneralUtility::makeInstance(Context::class)`.

To simulate another point in time, set the date aspect instead of writing to
`$GLOBALS['SIM_ACCESS_TIME']`:

```php
use TYPO3\CMS\Core\Context\DateTimeAspect;
use TYPO3\CMS\Core\Domain\DateTimeFactory;

$context->setAspect('date', new DateTimeAspect(DateTimeFactory::createFromTimestamp($timestamp)));
```