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
>>> 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));"
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));"
Passing -1 does what I would expect: it takes 1 second off the current
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
$ 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',
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.
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php