Re: cvs: php4 /ext/standard datetime.c
| From: | Zeev Suraski | Date: | Wed, 14 Jun 2000 21:04:55 +0000 |
| Subject: | Re: cvs: php4 /ext/standard datetime.c | ||
| References: | 1 | Groups: | php.cvs |
| Request: | Send a blank email to php-cvs+get-267@lists.php.net to get a copy of this message | ||
At 19:59 14/06/2000, Rasmus Lerdorf wrote:
I don't quite understand this fix. Why only require the year to be a long and not month & day. Also think of checkdate("12","12","12"); Why shouldn't this work? What is wrong with just using convert_to_long_ex() for all three? If the user sends junk then like the rest of PHP it will convert it to a number and he'll get a wrong result; or bad input should be handled in a more consistent way. Well, something like "abc" will be converted to 0 which is invalid for the day and the month arguments. However, 0 is a valid year argument. Saying that checkdate(12,12,'abc') is a valid date sucks.I really think that keeping it that way is not an option. It *will* break every script that uses checkdate() to verify form input. I'm not sure whether we should start testing for argument types wherever certain argument types don't make sense. There are hundreds if not thousands of such places. The approach in PHP has pretty much always been "send dumb arguments, get a dumb result". I don't really see how checkdate() is different - make a dumb call to checkdate(), and you'd get a dumb result (the same would happen if someone sends a very very large negative number, that will underflow and go back to a positive number, just for example). Even if you feel strongly about it, at the very least it has to accept floating point and string values, so that it doesn't break old scripts (I wouldn't get into this if I were you, but I'm not :). Zeev -- Zeev Suraski <zeev@zend.com> http://www.zend.com/