On 17 Nov 2011, at 20:17, Tedd Sperling wrote: > On Nov 17, 2011, at 11:58 AM, Stuart Dallas wrote: >> The epoch specifies the exact time that 0 represents. It makes no claims as far as that being the start of anything... >> >> "defined as the number of seconds elapsed since midnight Coordinated Universal Time (UTC) of Thursday, January 1, 1970 (Unix times are defined, but negative, before that date)" [http://en.wikipedia.org/wiki/Unix_time] > > Good reference to support your point, but strtotime() doesn't qork that way. In addition, the statement does not address where the fractions of a second were that occurred before the completion of the first second, clearly those fractions occurred in 1970. It certainly does address that. The definition "the number of seconds elapsed" says nothing about whole seconds, so I'd venture that fractions of a second are still covered. >>> 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. What would you expect "0" as the specification of either an absolute or relative time string to represent? Now, or the unix timestamp 0? Me, I'd call it an invalid argument, and PHP 5.3 happens to agree with me... $ php -r "var_dump(strtotime(0));" bool(false) It does that whether the 0 is passed as a string or a number. Seems right to me. > In addition, passing -1 through strtotime() simply returns today, whereas 'null' returns a date prior to the start of everything and that makes more logical sense to me. Not on my machine (PHP 5.3). Passing -1 does what I would expect: it takes 1 second off the current timestamp... $ php -r "echo date('r', strtotime(-1));" Fri, 18 Nov 2011 01:40:53 +0000 And passing null equally does the right thing, which is to return an error... $ php -r "var_dump(strtotime(null));" bool(false) Passing -1 does what I would expect: it takes 1 second off the current timestamp... Geoff is quite right to point out that strtotime is not the best way to test whether null is Wednesday, date is a better choice. Let's see what we get on 5.3. As expected, 0 == the epoch... $ php -r "date_default_timezone_set('UTC'); echo date('r', 0);" Thu, 01 Jan 1970 00:00:00 +0000 And -1 == 1 second before the epoch... $ php -r "date_default_timezone_set('UTC'); echo date('r', -1);" Wed, 31 Dec 1969 23:59:59 +0000 And null... $ php -r "date_default_timezone_set('UTC'); echo date('r', null);" Thu, 01 Jan 1970 00:00:00 +0000 So null is (well, was) a Thursday in UTC. It was a Wednesday on the west coast of the US... $ php -r "date_default_timezone_set('America/Los_Angeles'); echo date('r', null);" Wed, 31 Dec 1969 16:00:00 -0800 ...but I'm not in the US and it's not BST! Since it's now Friday where I am, time for a quick plug of the app I've been involved with for a few years now, and which finally had a public launch this week: http://datasift.com/. Lovely. TTFN :) -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
