Activity

PARAM_FLOAT worries me. Floats are not precise, and there is no guarantee what they are in PHP. Typically they are IEEE double, which gives you more than 32 bits for the mantissa, so they can be used to reliably represent bigger ints, but the point at which they stop working is not clear.

Also, there is no guarantee that PHP can do anything with these FLOATS when you call any of the date functions. E.g. http://php.net/manual/en/function.strftime.php says it takes an int as an argument, and there is a warning about out-of-int-range values.

Is it worth introducing a PARAM_DATESTAMP for this? That would better document what is going on, and make it easier to change in future. Hmm. I guess that does not work, because we are taking web services here, so the whole point is to document our internals for people who want to call Moodle.

Tim Hunt
added a comment - 16/Aug/12 1:39 PM PARAM_FLOAT worries me. Floats are not precise, and there is no guarantee what they are in PHP. Typically they are IEEE double, which gives you more than 32 bits for the mantissa, so they can be used to reliably represent bigger ints, but the point at which they stop working is not clear.
Also, there is no guarantee that PHP can do anything with these FLOATS when you call any of the date functions. E.g. http://php.net/manual/en/function.strftime.php says it takes an int as an argument, and there is a warning about out-of-int-range values.
Is it worth introducing a PARAM_DATESTAMP for this? That would better document what is going on, and make it easier to change in future. Hmm. I guess that does not work, because we are taking web services here, so the whole point is to document our internals for people who want to call Moodle.

Jérôme Mouneyrac
added a comment - 17/Aug/12 10:44 AM Ah I found the range explanation in the Note of http://php.net/manual/en/function.strtotime.php where it's saying:
The valid range of a timestamp is typically from Fri, 13 Dec 1901 20:45:54 UTC to Tue, 19 Jan 2038 03:14:07 UTC.
I checked on Moodle, if I create by web service a timestamp over 2020, it doesn't make sens on the user interface, as for example you can not have a start date after 2020 for a course.
I'll fix the PHP unit test timestamp.
Otherwise I do think it would be good to have a PARAM_TIMESTAMP, so we could return a more appropriate error than this is not an int.

I will not be able to work on this issue in the immediate future. In order to create a truer sense of the state of this issue and to allow other developers to have chance to become involved, I am removing myself as the assignee of this issue.

Jérôme Mouneyrac
added a comment - 20/May/13 7:53 AM I will not be able to work on this issue in the immediate future. In order to create a truer sense of the state of this issue and to allow other developers to have chance to become involved, I am removing myself as the assignee of this issue.
For more information, see http://docs.moodle.org/dev/Changes_to_issue_assignment