On 19 Nov 2011, at 16:48, Tedd Sperling wrote: >>>>> For example, if you push '-1' though strtotime(-1), you'll get Wednesday >>>>> only one day a week -- whereas 'null' works every time. >>>> Technically I see that as a bug. I believe strtotime(null) should return >>>> null, but due to the way type inference works, null is interpreted as 0. >>>> The point here being that you're not getting the time at null, you're >>>> getting the time at 0. >>> >>> Nope, zero time is absolutely January 1, 1970 00:00:00 -- which was a >>> Thursday. If you pass zero through strtotime(), it reports "December 1969" >>> and I claim that to be a bug. Realize that seconds, minutes, and hours go >>> from 0-59, not 1 to 60. Any fractions of a second before zero was 59.999... >>> and such was indeed part of the day/month/year before. >> >> That has nothing to do with seconds running from 0 to 59 rather than 1 to >> 60, it has to do with your timezone. When you ask PHP to display a formatted >> date with a timestamp of 0 you're actually getting the time at (unix >> timestamp 0 + (3600 * your timezone offset in hours)). Since you're in a >> timezone that's behind UTC you get the previous day. > >> -snip- with other time zone discussion that have nothing to do with what I >> observed nor addressed in my post. > > My observations are demonstrated here: > > http://www.webbytedd.com/cccc/strtotime/index.php
Your test code is flawed because strtotime returns an error when you pass it null. Your code is passing that false to getdate, which is interpreting it as an integer, which would be 0. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
