TYPO3 Core

a workaround would be:

20.value = UNIX_TIMESTAMP()

What is your intention about assigning U to 20.date?

The documentation says:
The content should be data-type "UNIX-time".

I do agree to change the behavior to prevent this warning.
Can you push a patch to gerrit?

My intention is to get the current timestamp which is only possible in typo3 with typoscript like that.

No behaviour needs to be changed, just the error handling... (if no "parameter"/$content is given)

Can you push a patch to gerrit?

yes, sure.

Patch set 2 of change I44d095deb7b511b8b35730f2f031186aeaadb945 has been pushed to the review server.
It is available at http://review.typo3.org/5821

Patch set 3 of change I44d095deb7b511b8b35730f2f031186aeaadb945 has been pushed to the review server.
It is available at http://review.typo3.org/5821

date() and gmdate() convert a big range of values to an integer:

integers : OK
floats : OK
NULL : OK ( => zero)
hex / decimal direct values : OK (like in date( 'U', 0xFF); )
strings:
- whitespace at beginning allowed (' 1234')
- trailing non-numeric garbage is ignored ( '1234abc' => 1234, but also '0xFFyyyy' => 255)
- +/- signs at beginning allowed ('+0' => 0

Next version will use a regular expression to check string values for validity.

Patch set 4 of change I44d095deb7b511b8b35730f2f031186aeaadb945 has been pushed to the review server.
It is available at http://review.typo3.org/5821

@Jigal van Hemert: did/could you write some unit tests for that?

Jigal, I'm sure you're referencing to this:
www.php.net/manual/en/language.types.integer.php

• I can't find any hint that date() is accepting floats.
• Where does it say that leading white spaces are trimmed automatically?

I do believe a simple intval() or is_numeric() check would suffice.

I checked the internal source code of PHP where it uses a function to 'interpret' a parameter to a long (integer) value. This function is different than intval() or is_numeric() uses. For example date('U', '0xFFyyy') = 255 while intval('0xFFyyy') = 0 and is_numeric('0xFFyyy') = FALSE.

The problem with this issue is that we have to make sure that things that worked before will still work (especially for 4.5 and 4.4 branches), while getting rid of the ugly warnings.

Below a small test script to see what date() accepts and that the regexp matches this (at least for strings).

Unit tests would be very nice indeed.

<?php
$date = array('-2text1',0,'-0', 12345678, '0020', '0xFFyyy', '-0xEEyyy', '-1.0e4', '   12345.6', '12345,7', 12345.6, NULL, TRUE, ' +    1234567abc', 'plaap', '');
foreach ($date as $tryDate) {
    echo 'tryDate: ';
    var_export($tryDate);
    echo "<br />\nis_numeric: ";
    var_export(is_numeric($tryDate));
    echo "<br />\nintval: ";
    var_export(intval($tryDate));
    echo "<br />\nusing testAgainstRegexp: ";
    var_export(testAgainstRegexp($tryDate));

    echo "<br />\ndate('U' : ";
    $plaap = date('U', $tryDate);
    var_export($plaap);
    echo "<br />\ngmdate('U' : ";
    $plaap = gmdate('U', $tryDate);
    var_export($plaap);
    echo "<br />\n";
    echo "--------------------<br />\n";
}

    function testAgainstRegexp ($value) {
        return preg_match('/^[[:space:]]* #allow whitespace at beginning
                    (
                        [+-]?(\d+)(?![xX]) #(un)signed decimal which is not the start of a hexadecimal number
                        |
                        0[xX][0-9a-fA-F]+ #unsigned hexadecimal number
                        |
                        [+-]?((\d+|((\d*\.\d+)|(\d+\.\d*)))[eE][+-]?\d+) #floating point notation
                    )
                    /x', $value);    
    }
?>

Do we really need that complexity? Why don't we simply do intval? What is the use case for having 0x23427235 as a string parameter?

I'd say go for a simple integer for now and expand that in future if there is a real use case for this. There is no need for complicating this more than necessary.

Patch set 5 of change I44d095deb7b511b8b35730f2f031186aeaadb945 has been pushed to the review server.
It is available at http://review.typo3.org/5821

Patch set 6 of change I44d095deb7b511b8b35730f2f031186aeaadb945 has been pushed to the review server.
It is available at http://review.typo3.org/5821

Patch set 7 of change I44d095deb7b511b8b35730f2f031186aeaadb945 has been pushed to the review server.
It is available at http://review.typo3.org/5821