Re: cvs: php4 /ext/standard datetime.c

Zeev Suraski wrote: > > 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 :). > what about redefining the valid range of years as starting from year one instead of zero here? that shouldn't break to much and fix the problem for this case (anybody operating with dates before 1970 should be using the calendar extensions and julian days anyway, so loosing year 0 shouldn't harm) this ain't a general solution, but as a quick shot for checkdate() it should be ok ?!?