class.baserecurrence.php date() expects parameter 2 to be integer, float given (2)

Manfred

Hi Rayman,

is it a 32-bit system?

Manfred

it is a new raspberry pi 3 b+.
It has an ARMv8 (64 Bit) BUT IT RUNS IN 32 BIT MODE and pretends to be a armv7l .

So yes, 32bit

Manfred

Hi Rayman,

I guess what happens on your system is the integer overflow: http://php.net/manual/en/language.types.integer.php#language.types.integer.overflow

You could add something like
ZLog::Write(LOGLEVEL_DEBUG, sprintf("GetTZOffset: '%s'", $ts));
to the line 1396 of /usr/local/share/z-push/backend/kopano/mapi/class.baserecurrence.php and post the log entry.

Manfred

…syntax error, unexpected ‘:’, expecting ‘,’ or ‘)’ (4)
can you see the problem? I’m searching

do i have to escape the : or something? I’m not a good php developer

Manfred

Hi Rayman,

it’s probably the forum software replacing quotes and single quotes with fancier ones :(. I’ve put the line in the code block, please try again.

Manfred

ok, sure, that the fault :-)
.
.
.
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1544860800’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1519776000’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1522548000’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1538265600’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1541300400’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1544864400’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1519776000’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1522548000’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1538265600’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1541300400’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1544918400’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1545004800’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1545091200’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1545177600’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1545264000’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1545350400’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1545436800’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1545465600’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1519776000’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1522548000’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1538265600’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1541300400’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1545469200’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1519776000’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1522548000’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1538265600’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1541300400’
15/01/2019 19:31:34 [ 8084] [DEBUG] [tim] GetTZOffset: ‘1545523200’
.
.
.

Manfred

Hi Rayman,

those numbers are smaller than PHP max integer on a 32-bit system. Were the error messages still there?

Did you check apache logs if similar entries are there when using webapp?

It might be that PHP on your system behaves differently somehow causing the int to float conversion.

Manfred

Hi Manfred,

your guess was right. It it is a 32 bit problem.
The error occurs not with every function call. I’ve extended the log output with the datatype:

16/01/2019 08:12:31 [16176] [WARN] [tim] GetTZOffset: ‘1562313600’ is datatype: ‘integer’
16/01/2019 08:12:31 [16176] [WARN] [tim] GetTZOffset: ‘1551312000’ is datatype: ‘integer’
16/01/2019 08:12:31 [16176] [WARN] [tim] GetTZOffset: ‘1553392800’ is datatype: ‘integer’
16/01/2019 08:12:31 [16176] [WARN] [tim] GetTZOffset: ‘1569801600’ is datatype: ‘integer’
16/01/2019 08:12:31 [16176] [WARN] [tim] GetTZOffset: ‘1572750000’ is datatype: ‘integer’
16/01/2019 08:12:31 [16176] [WARN] [tim] GetTZOffset: ‘1562317200’ is datatype: ‘integer’
16/01/2019 08:12:31 [16176] [WARN] [tim] GetTZOffset: ‘1551312000’ is datatype: ‘integer’
16/01/2019 08:12:31 [16176] [WARN] [tim] GetTZOffset: ‘1553392800’ is datatype: ‘integer’
16/01/2019 08:12:31 [16176] [WARN] [tim] GetTZOffset: ‘1569801600’ is datatype: ‘integer’
16/01/2019 08:12:31 [16176] [WARN] [tim] GetTZOffset: ‘1572750000’ is datatype: ‘integer’
16/01/2019 08:12:31 [16176] [WARN] [tim] GetTZOffset: ‘1459728000’ is datatype: ‘integer’
16/01/2019 08:12:31 [16176] [WARN] [tim] GetTZOffset: ‘79870665540’ is datatype: ‘double’
16/01/2019 08:12:31 [16176] [WARN] [tim] /usr/local/share/z-push/backend/kopano/mapi/class.baserecurrence.php:1396 date() expects parameter 2 to be integer, float given (2)
16/01/2019 08:12:31 [16176] [WARN] [tim] /usr/local/share/z-push/backend/kopano/mapi/class.baserecurrence.php:1414 localtime() expects parameter 1 to be integer, float given (2)
16/01/2019 08:12:31 [16176] [WARN] [tim] GetTZOffset: ‘’ is datatype: ‘boolean’
16/01/2019 08:12:31 [16176] [WARN] [tim] GetTZOffset: ‘2685600’ is datatype: ‘integer’
16/01/2019 08:12:31 [16176] [WARN] [tim] GetTZOffset: ‘’ is datatype: ‘boolean’
16/01/2019 08:12:31 [16176] [WARN] [tim] GetTZOffset: ‘2689200’ is datatype: ‘integer’
16/01/2019 08:12:31 [16176] [WARN] [tim] GetTZOffset: ‘1563174751’ is datatype: ‘integer’
16/01/2019 08:12:31 [16176] [WARN] [tim] GetTZOffset: ‘1551312000’ is datatype: ‘integer’
16/01/2019 08:12:31 [16176] [WARN] [tim] GetTZOffset: ‘1553997600’ is datatype: ‘integer’
16/01/2019 08:12:31 [16176] [WARN] [tim] GetTZOffset: ‘1569801600’ is datatype: ‘integer’
16/01/2019 08:12:31 [16176] [WARN] [tim] GetTZOffset: ‘1572750000’ is datatype: ‘integer’
16/01/2019 08:12:31 [16176] [WARN] [tim] GetTZOffset: ‘1563181951’ is datatype: ‘integer’
16/01/2019 08:12:31 [16176] [WARN] [tim] GetTZOffset: ‘1459728000’ is datatype: ‘integer’
.
.
.
is it possible to give the date function a float somehow? by casting or similar? or a date function with a float as timestamp?

Why has the the timestamp such a big value? ist that correct?
Thank you for your good support!!!

Manfred

Hi Rayman,

I suppose the only way to pass a float to date function without getting that error would be to modify date function and then compile PHP yourself because it’s the PHP itself which throws the error.

The only easy workaround I can think of is to check the datatype as you did in the log output and set the value to PHP max integer if it’s not an integer. That high value (79870665540) is to mark the end of the recurrence which is never ending (technically it then will end at 31.12.4500 but that’s far enough away). If you set that to PHP max integer, it would end at 19.01.2038 which would delay your issue for the next 19 years.

Something like that before you pass $ts to date function (line 1395):

            if (is_numeric($ts) && !is_int($ts)) {
                $ts = PHP_INT_MAX;
            }

Manfred

ok, perfect. Thank you for the explanation.
I added the following code to the two functions:


  /**
        * gmtime() doesn't exist in standard PHP, so we have to implement it ourselves
        * @author Steve Hardy
        */
        function GetTZOffset($ts)
        {
            if (is_numeric($ts) && !is_int($ts) && $ts > PHP_INT_MAX){
                $ts = PHP_INT_MAX;
                ZLog::Write(LOGLEVEL_INFO, sprintf("BaseRecurrence->GetTZOffset(): Timestamp overflow. Set timestamp to : '%s'", PHP_INT_MAX));
            }
            $Offset = date("O", $ts);
            $Parity = $Offset < 0 ? -1 : 1;

and

/**
        * gmtime() doesn't exist in standard PHP, so we have to implement it ourselves
        * @author Steve Hardy
        * @param Date $time
        * @return Date GMT Time
        */
        function gmtime($time)
        {

            if (is_numeric($time) && !is_int($time) && $time > PHP_INT_MAX){
                $time = PHP_INT_MAX;
                ZLog::Write(LOGLEVEL_INFO, sprintf("BaseRecurrence->gmtime(): Timestamp overflow. Set timestamp to : '%s'", PHP_INT_MAX));
            }

             $TZOffset = $this->GetTZOffset($time);

is it possible for you, to add such a function to the official code. I could update to the next version easily :-) and it would work on 32bit machine.

Btw:
is an official raspberry pi support planned? In contrast to the old zarafa version(I used an old version), the Kopano runs very fast on the pi.
It is perfect to store the mobile phone stuff at home with low budget and power consumption outside of the big unsecure clouds. Thank you!!!

fbartels

@Rayman said in class.baserecurrence.php date() expects parameter 2 to be integer, float given (2):

is an official raspberry pi support planned?

No, a specific support for the raspberry pi is not planned. We have done quite some performance improvements over the last months (since forking to Kopano actually), glad to hear that this also provides some more performance for such low end systems.

We are discontinuing more and more 32bit builds, for our customers we actually only support 64bit (as our architecture still greatly benefits from ram for caching). There seems to be official support for arm64 coming with Debian Buster, so my recommendation would be to switching over to a 64bit os.

ok, i think that I compile the next version on the Buster OS in future, thank you.
Yes, the Kopano is faster. factor 10 i think.
But i changed my rpi from rpi 1b+ to 3b+. So i’m not sure were the closest bottleneck was.
Kr
Tim