Point::isValidTimestamp() does not allow nanoseconds about influxdb-php

[mermetbt]

I don't think InfluxDB accept float or double values as timestamp, need to be check.

Another strange behavior is if you put a string in input like '2015-10-27 14:17:40', the method isValidTimestamp will return true because of PHP behavior.
The first test (int)$timestamp === $timestamp will be false, but we continue to check... that's not a good behavior. And in the second check PHP will consider the string as a numeric value (1) and the test $timestamp <= PHP_INT_MAX && $timestamp >= ~PHP_INT_MAX will be true. So the method return true on string values...

[andig]

I don't think InfluxDB accept float or double values as timestamp, need to be check.

I don't expect it to, but the timestamp check function should accept nanosec timestamps which it doesn't. Right now its very much borked.

[mermetbt]

In fact, it can't work on 32bits systems, but on 64bits system it's supported until this date: 294247-01-09 20:00:54 which is I think long enough :-p
On 32bits systems: PHP_MAX_INT is equal to 2,147,483,647 (10 digits)
On 64bits systems: PHP_MAX_INT is equal to 9,223,372,036,854,775,807 (19 digits)

[thecodeassassin]

@andig what @mermetbt says is correct. We expect the script to be run on 64 bit systems only.

[andig]

In fact, it can't work on 32bits systems

True for the current implementation. If you wanted to support 32 bits you could allow doubles or even strings and use ctype_digit

[thecodeassassin]

@andig

ctype_digit won't work because it doesn't accept the - character (which means you cannot supply dates before the unix epoch). There are cases where you might need to enter dates before the unix epoch. However we will add the following statement to the isValidTimestamp method:

// if the code is run on a 32bit system, loosely check if the timestamp is a valid numeric
if (PHP_INT_SIZE == 4 && is_numeric($timestamp) && intval($timestamp) == $timestamp) {
    return true;
}

[thecodeassassin]

@andig this issue has been addressed in 1.2.x

[andig]

It maybe me who doesn't get it, but intval will again be limited to 32bits. Doubles arent- so stay with isnumeric instead?

[thecodeassassin]

@andig correct i will have to remove the intval() function from the equation. I'm retagging 1.2.1 with this change. Thanks!