Bug #94621

startime/endtime are forced to "today" after saving

Added by Xavier Perseguers 3 months ago. Updated about 1 month ago.

Must have
DataHandler aka TCEmain
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


Since v10.4.18 we face a regression when using @'range' on a date/time field.

How to reproduce

Take any TCA definition and put some lower constraint on the range of startime and/or endtime. Here is an example of such a problematic definition (which originates back from many versions of TYPO3):

        'endtime' => [
            'exclude' => 1,
            'label' => 'LLL:EXT:core/Resources/Private/Language/locallang_general.xlf:LGL.endtime',
            'config' => [
                'type' => 'input',
                'size' => 13,
                'eval' => 'datetime',
                'checkbox' => 0,
                'default' => 0,
                'range' => [
                    'lower' => mktime(0, 0, 0, date('m'), date('d'), date('Y'))
                'behaviour' => [
                    'allowLanguageSynchronization' => true,
                'renderType' => 'inputDateTime',

Even if that definition not really makes sense anymore since TCA is cached since TYPO3 v9, this was never a problem but is suddenly breaking (typically) custom records:

  • Create a (or update an existing) record having those starttime, endtime
  • Upon saving the (empty) start/end fields are now populated with the date on midnight (+ GMT/timezone offset) of the day you last cleared the whole cache
  • You CANNOT clear that field again

This is highly breaking because typically for the endtime field, this has impact on records you create/edit and can be particularly weird in relation with IRRE where you don't always see that such a visibility restriction has been enforced.


Thanks to Benni, it looks like that the culprit commit is https://git.typo3.org/Packages/TYPO3.CMS.git/blobdiff/ae55eef595bdd4d0676d3b9d96cfc08a4f327527..adce6dbe8b305c71c447929bc14e5c87b4ad6954:/typo3/sysext/core/Classes/DataHandling/DataHandler.php

and particularly (for me, by reading) to this part:

+            && (
+                !isset($tcaFieldConf['default'])
+                || floor($res['value']) !== (int)$tcaFieldConf['default']
+                || ceil($res['value']) !== (int)$tcaFieldConf['default']
+            )

Indeed, there's the use of ceil() and floor() with a strict comparison with an int-cast of the default value. having "0" as value in the field (if empty), leads to floor() and ceil() to return a double which is strictly compared to an int and can logically never be true.


Again, by reading only, not tested so far:

+            && (
+                !isset($tcaFieldConf['default'])
+                || (int)floor($res['value']) !== (int)$tcaFieldConf['default']
+                || (int)ceil($res['value']) !== (int)$tcaFieldConf['default']
+            )

Related issues

Related to TYPO3 Core - Task #94658: Raise typo3/cms-styleguide to 11.4.0Closed2021-07-28

Related to TYPO3 Core - Bug #94527: Range validation in DataHandler has useless if statement partClosed2021-07-10

Has duplicate TYPO3 Core - Bug #94603: int-validation in TCA does not accept empty value, when lower-range is definedClosed2021-07-21

Has duplicate TYPO3 Core - Bug #94676: starttime/endtime is set automatically in 10.4.18 in serveral extensionsClosed2021-07-30

Has duplicate TYPO3 Core - Bug #94711: Date input with lower range inserts value even if no value is set since TYPO3 10.4.18Closed2021-08-04

Follows TYPO3 Core - Bug #94103: TCA input range does not work well with eval doubleClosed2021-05-10


Also available in: Atom PDF