php-general Digest 18 Nov 2011 05:40:26 -0000 Issue 7573
Topics (messages 315722 through 315740):
Re: Sniping on the List
315722 by: Tedd Sperling
315723 by: Stuart Dallas
315724 by: Tedd Sperling
315725 by: HallMarc Websites
315727 by: Stuart Dallas
315728 by: Robert Cummings
315729 by: Tamara Temple
315730 by: Tamara Temple
315733 by: Tedd Sperling
315734 by: Geoff Shang
315735 by: Fredric L. Rice
315736 by: Fredric L. Rice
315737 by: Stuart Dallas
315738 by: George Langley
315739 by: Stuart Dallas
315740 by: Robert Cummings
Re: Think I found a PHP bug
315726 by: Tim Streater
socket_recv
315731 by: Tim Streater
315732 by: Mike Mackintosh
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On Nov 15, 2011, at 2:54 PM, Steven Staples wrote:
>> <tamouse.li...@gmail.com> sent:
>>> <tedd.sperl...@gmail.com> wrote:
>>>> PS: I know it's not Friday, but this question came up in class
>>>> yesterday and I thought maybe all of you might like to guess why
>>>> null is Wednesday?
>>>
>>> Wait.. What??
>>>
>>> $ php -r 'echo date("l",NULL),"\n";'
>>> Wednesday
>>>
>>> Cos:
>>>
>>> $ php -r 'echo date("r",NULL),"\n";'
>>> Wed, 31 Dec 1969 18:00:00 -0600
>>>
>>> (Personally, I would have thought Thursday should be NULL, but that's
>>> just me. And Thursday.)
>>
>> Actually, It *is* Thursday if you use UTC:
>>
>> $ TZ=UTC php -r 'echo date("r",NULL),"\n";'
>> Thu, 01 Jan 1970 00:00:00 +0000
>>
>> :P
>
> Perfect example of Tedd's last comment about being proven wrong (even though
> TECHNICALLY it isn't)
>
> Good job :)
To all:
Okay, so now that we have had people reply, here's my take.
The Unix timestamp started on 01 Jan 1970 00:00:00 +0000 -- and that was a
Thursday.
The second before (i.e., 31 December, 1969 23:59:59:59 + 0000) was null, which
was Wednesday.
Now one might argue that everything before was null and I could accept that.
But here's my code and reasoning, please follow:
$string = null;
$seconds = strtotime($string); // change string into seconds
date = getdate($seconds); // change seconds into a date
$computedDate = $date['mday'] . ' ' . $date['month'] . ', ' . $date['year'] . '
: ' .$date['weekday'];
echo($computedDate); // show date
Thus, null is Wednesday.
Now, why is this wrong?
Cheers,
tedd
_____________________
t...@sperling.com
http://sperling.com
--- End Message ---
--- Begin Message ---
On 17 Nov 2011, at 16:01, Tedd Sperling wrote:
> To all:
>
> Okay, so now that we have had people reply, here's my take.
>
> The Unix timestamp started on 01 Jan 1970 00:00:00 +0000 -- and that was a
> Thursday.
>
> The second before (i.e., 31 December, 1969 23:59:59:59 + 0000) was null,
> which was Wednesday.
I take issue with this. The second before was -1 seconds from the epoch. Null
is the absence of a value, so you can't get to null by simple arithmetic. I
learnt about negative numbers from the Greeks. And no, I'm not going to comment
on their current mathematical difficulties.
Hmm.
D'oh!
But the point still stands: -1 !== null.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
On Nov 17, 2011, at 11:07 AM, Stuart Dallas wrote:
> On 17 Nov 2011, at 16:01, Tedd Sperling wrote:
> To all:
>>
>> Okay, so now that we have had people reply, here's my take.
>>
>> The Unix timestamp started on 01 Jan 1970 00:00:00 +0000 -- and that was a
>> Thursday.
>>
>> The second before (i.e., 31 December, 1969 23:59:59:59 + 0000) was null,
>> which was Wednesday.
>
> I take issue with this. The second before was -1 seconds from the epoch. Null
> is the absence of a value, so you can't get to null by simple arithmetic. I
> learnt about negative numbers from the Greeks. And no, I'm not going to
> comment on their current mathematical difficulties.
>
> Hmm.
>
> D'oh!
>
> But the point still stands: -1 !== null.
>
> -Stuart
Leave it to you to get all Greek on me. :-)
Consider this -- do you think the second before the "Big Bang" was negative or
null?
Likewise, the Unix timestamp was defined to start at a specific point in time
-- it does not address/define what time came before. Thus, what came before was
not negative, but rather 'undefined'. I claim 'null' is a better fit for
'undefined' than negative -- plus it works.
For example, if you push '-1' though strtotime(-1), you'll get Wednesday only
one day a week -- whereas 'null' works every time.
My point stands: null == Wednesday. :-)
Cheers,
tedd
_____________________
t...@sperling.com
http://sperling.com
--- End Message ---
--- Begin Message ---
>
> > To all:
> >
> > Okay, so now that we have had people reply, here's my take.
> >
> > The Unix timestamp started on 01 Jan 1970 00:00:00 +0000 -- and that was
a
> Thursday.
> >
> > The second before (i.e., 31 December, 1969 23:59:59:59 + 0000) was null,
> which was Wednesday.
>
> I take issue with this. The second before was -1 seconds from the epoch.
Null
> is the absence of a value, so you can't get to null by simple arithmetic.
I learnt
> about negative numbers from the Greeks. And no, I'm not going to comment
> on their current mathematical difficulties.
>
> Hmm.
>
> D'oh!
>
> But the point still stands: -1 !== null.
>
> -Stuart
>
What if we were to throw in quantum duality in here? Null and !Null at the
same time
--- End Message ---
--- Begin Message ---
On 17 Nov 2011, at 16:33, Tedd Sperling wrote:
> On Nov 17, 2011, at 11:07 AM, Stuart Dallas wrote:
>> On 17 Nov 2011, at 16:01, Tedd Sperling wrote:
>> To all:
>>>
>>> Okay, so now that we have had people reply, here's my take.
>>>
>>> The Unix timestamp started on 01 Jan 1970 00:00:00 +0000 -- and that was a
>>> Thursday.
>>>
>>> The second before (i.e., 31 December, 1969 23:59:59:59 + 0000) was null,
>>> which was Wednesday.
>>
>> I take issue with this. The second before was -1 seconds from the epoch.
>> Null is the absence of a value, so you can't get to null by simple
>> arithmetic. I learnt about negative numbers from the Greeks. And no, I'm not
>> going to comment on their current mathematical difficulties.
>>
>> Hmm.
>>
>> D'oh!
>>
>> But the point still stands: -1 !== null.
>>
>> -Stuart
>
> Leave it to you to get all Greek on me. :-)
>
> Consider this -- do you think the second before the "Big Bang" was negative
> or null?
I don't know. There's no point concerning ourselves with unanswerable questions.
> Likewise, the Unix timestamp was defined to start at a specific point in time
> -- it does not address/define what time came before. Thus, what came before
> was not negative, but rather 'undefined'. I claim 'null' is a better fit for
> 'undefined' than negative -- plus it works.
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]
> 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.
> My point stands: null == Wednesday. :-)
It may stand, but it's standing on foundations of null space :)
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
On 11-11-17 11:33 AM, HallMarc Websites wrote:
To all:
Okay, so now that we have had people reply, here's my take.
The Unix timestamp started on 01 Jan 1970 00:00:00 +0000 -- and that was
a
Thursday.
The second before (i.e., 31 December, 1969 23:59:59:59 + 0000) was null,
which was Wednesday.
I take issue with this. The second before was -1 seconds from the epoch.
Null
is the absence of a value, so you can't get to null by simple arithmetic.
I learnt
about negative numbers from the Greeks. And no, I'm not going to comment
on their current mathematical difficulties.
Hmm.
D'oh!
But the point still stands: -1 !== null.
-Stuart
What if we were to throw in quantum duality in here? Null and !Null at the
same time
False
Cheers,
Rob.
--
E-Mail Disclaimer: Information contained in this message and any
attached documents is considered confidential and legally protected.
This message is intended solely for the addressee(s). Disclosure,
copying, and distribution are prohibited unless authorized.
--- End Message ---
--- Begin Message ---
On Nov 17, 2011, at 10:33 AM, Tedd Sperling <tedd.sperl...@gmail.com>
wrote:
On Nov 17, 2011, at 11:07 AM, Stuart Dallas wrote:
On 17 Nov 2011, at 16:01, Tedd Sperling wrote:
To all:
Okay, so now that we have had people reply, here's my take.
The Unix timestamp started on 01 Jan 1970 00:00:00 +0000 -- and
that was a Thursday.
The second before (i.e., 31 December, 1969 23:59:59:59 + 0000) was
null, which was Wednesday.
I take issue with this. The second before was -1 seconds from the
epoch. Null is the absence of a value, so you can't get to null by
simple arithmetic. I learnt about negative numbers from the Greeks.
And no, I'm not going to comment on their current mathematical
difficulties.
Hmm.
D'oh!
But the point still stands: -1 !== null.
-Stuart
Leave it to you to get all Greek on me. :-)
Consider this -- do you think the second before the "Big Bang" was
negative or null?
Likewise, the Unix timestamp was defined to start at a specific
point in time -- it does not address/define what time came before.
Thus, what came before was not negative, but rather 'undefined'. I
claim 'null' is a better fit for 'undefined' than negative -- plus
it works.
For example, if you push '-1' though strtotime(-1), you'll get
Wednesday only one day a week -- whereas 'null' works every time.
My point stands: null == Wednesday. :-)
Cheers,
tedd
_____________________
t...@sperling.com
http://sperling.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
As I clearly demonstrated, that depends on where you're standing :)
--- End Message ---
--- Begin Message ---
On Nov 17, 2011, at 10:01 AM, Tedd Sperling <tedd.sperl...@gmail.com>
wrote:
On Nov 15, 2011, at 2:54 PM, Steven Staples wrote:
<tamouse.li...@gmail.com> sent:
<tedd.sperl...@gmail.com> wrote:
PS: I know it's not Friday, but this question came up in class
yesterday and I thought maybe all of you might like to guess why
null is Wednesday?
Wait.. What??
$ php -r 'echo date("l",NULL),"\n";'
Wednesday
Cos:
$ php -r 'echo date("r",NULL),"\n";'
Wed, 31 Dec 1969 18:00:00 -0600
(Personally, I would have thought Thursday should be NULL, but
that's
just me. And Thursday.)
Actually, It *is* Thursday if you use UTC:
$ TZ=UTC php -r 'echo date("r",NULL),"\n";'
Thu, 01 Jan 1970 00:00:00 +0000
:P
Perfect example of Tedd's last comment about being proven wrong
(even though TECHNICALLY it isn't)
Good job :)
To all:
Okay, so now that we have had people reply, here's my take.
The Unix timestamp started on 01 Jan 1970 00:00:00 +0000 -- and that
was a Thursday.
The second before (i.e., 31 December, 1969 23:59:59:59 + 0000) was
null, which was Wednesday.
Now one might argue that everything before was null and I could
accept that. But here's my code and reasoning, please follow:
$string = null;
$seconds = strtotime($string); // change string into seconds
date = getdate($seconds); // change seconds into a date
$computedDate = $date['mday'] . ' ' . $date['month'] . ', ' . $date
['year'] . ' : ' .$date['weekday'];
echo($computedDate); // show date
Thus, null is Wednesday.
Now, why is this wrong?
Cheers,
tedd
_____________________
t...@sperling.com
http://sperling.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
That's just it -- it's not wrong -- it's just local
--- End Message ---
--- Begin Message ---
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.
>> 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.
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.
>> My point stands: null == Wednesday. :-)
>
> It may stand, but it's standing on foundations of null space :)
Been there many times. :-)
Cheers,
tedd
_____________________
t...@sperling.com
http://sperling.com
--- End Message ---
--- Begin Message ---
On Thu, 17 Nov 2011, 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.
Yes it does.
$ php -r 'echo strtotime ("31 Dec 1969 23:59 +0000");'
-60
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.
Not here it doesn't.
$ php -r 'echo date ("r", strtotime ("zero"));'
Thu, 01 Jan 1970 00:00:00 +0000
But it might for you (see below).
In addition, passing -1 through strtotime() simply returns today,
Here it returns a time an hour later than now.
$ date -R; php -r 'echo date ("r", strtotime ("-1"));'
Thu, 17 Nov 2011 20:41:06 +0000
Thu, 17 Nov 2011 21:41:07 +0000
whereas 'null' returns a date prior to the start of everything and that
makes more logical sense to me.
but here we hit the crux of the problem. 'strtotime("null")' isn't
returning a null timestamp, it's simply returning the value for an
inability to convert the string "null" to a timestamp.
Of course, now that I try to reproduce the "null == Wednesday" result, I
find that I can't. Everything comes up as Thu, 01 Jan 1970 00:00:00 +0000
which probably invalidates much of what I've written above. Maybe I'm not
running a new enough PHP (latest I have access to is 5.3.3). But if this
is the case, this suggests this behaviour changed relatively recently.
Anyway, as I was going to say, the correct way to find out what null is is
to do something like:
echo date ("r", null);
But this thread has gone through so many twists now that I can't remember
if this is where we began or not.
Geoff.
--- End Message ---
--- Begin Message ---
> What if we were to throw in quantum duality in here?
> Null and !Null at the same time
Please no, our company is trying to outsource to India and they're
constantly trying to shove things through narrow slits and the effect has
been costly.
--- End Message ---
--- Begin Message ---
>> Consider this -- do you think the second before
>> the "Big Bang" was negative or null?
> I don't know. There's no point concerning ourselves
> with unanswerable questions.
The question itself is a logical absurdity since there was no time prior
to the Big Bang. The advent of time began when the dimention we perceive
as the passage of time froze out of folded reality during the expansion
phases's symmertry breaking period, there is not only no answer to what
happened before, even suggesting there *was* a before is not possible.
It's another nail in the coffin of deity constructors.
--- End Message ---
--- Begin Message ---
On 17 Nov 2011, at 23:24, Fredric L. Rice wrote:
>>> Consider this -- do you think the second before
>>> the "Big Bang" was negative or null?
>> I don't know. There's no point concerning ourselves
>> with unanswerable questions.
>
> The question itself is a logical absurdity since there was no time prior
> to the Big Bang. The advent of time began when the dimention we perceive
> as the passage of time froze out of folded reality during the expansion
> phases's symmertry breaking period, there is not only no answer to what
> happened before, even suggesting there *was* a before is not possible.
Therefore suggesting that time did not exist "before" is as daft as suggesting
that the edges of the universe are being pulled away from us by a herd of randy
sloths. The big bang theory is based on an analysis of the effects we can
observe in the here and now, which is nowhere near proof that it's actually
what happened. Especially not when you consider that the only thing I (or you)
actually know is that I (or you) exist in some form, and everything else is a
guess based on incredibly flimsy evidence!
> It's another nail in the coffin of deity constructors.
Not even slightly.
But none of this has anything even vaguely related to PHP.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
>
>> It's another nail in the coffin of deity constructors.
-----
And just as this thread was getting boringly OT! ;-{)]
George Langley
Interactive Developer
www.georgelangley.ca
--- End Message ---
--- Begin Message ---
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/
--- End Message ---
--- Begin Message ---
On 11-11-17 06:24 PM, Fredric L. Rice wrote:
Consider this -- do you think the second before
the "Big Bang" was negative or null?
I don't know. There's no point concerning ourselves
with unanswerable questions.
The question itself is a logical absurdity since there was no time prior
to the Big Bang. The advent of time began when the dimention we perceive
as the passage of time froze out of folded reality during the expansion
phases's symmertry breaking period, there is not only no answer to what
happened before, even suggesting there *was* a before is not possible.
It's another nail in the coffin of deity constructors.
By you're reasoning since I did not exist before 1974 then time itself
could not possibly have existed before then either since I was not in
existence to perceive it. That's as ludicrous as suggesting time did not
exist before the big bang (presuming this model is correct). Also,
them's some fancy shmancy words you're slinging about up there, but
without a proof it's just farts in the wind :) No more valid than a
theory of creation or the big ass spaghetti thingy majingy dude. Folded
shmeality and phases of whatsyamacallit may well be true, but
provability of the non-existence of time before the big bang theory is
not provable by this model. However, what is valid is to take a point of
reference in time and infer a period before it. Thus before the big bang
is perfectly valid whether we could perceive it or not.
Cheers,
Rob.
--
E-Mail Disclaimer: Information contained in this message and any
attached documents is considered confidential and legally protected.
This message is intended solely for the addressee(s). Disclosure,
copying, and distribution are prohibited unless authorized.
--- End Message ---
--- Begin Message ---
On 16 Nov 2011 at 16:30, Geoff Shang <ge...@quitelikely.com> wrote:
> On Wed, 15 Nov 2011, Tim Streater wrote:
>
>> I find I need to do this:
>>
>> date_default_timezone_set (@date_default_timezone_get ());
>>
>> in all my scripts since 5.x.x to avoid rude messages.
>
> Apart from the fact that I've not seen the rude messages of which you
> speak, even though I expected to, this won't help in this case.
> date_default_timezone_get() is returning the wrong timezone.
Here's what I would otherwise get:
Warning: date(): It is not safe to rely on the system's timezone settings. You
are *required* to use the date.timezone setting or the
date_default_timezone_set() function. In case you used any of those methods and
you are still getting this warning, you most likely misspelled the timezone
identifier. We selected 'UTC' for 'GMT/0.0/no DST' instead in /Users/tim/....
--
Cheers -- Tim
--- End Message ---
--- Begin Message ---
I'm playing around with web sockets and have found a couple of simple servers
written in PHP. They both appear to perform the initial handshake with a client
but then just give up because socket_recv reports that there is no data. I'm
confused by this as, the handshake being complete, I wouldn't expect there to
be any data if the client hasn't sent any. Is there a way to wait with timeout
on data showing up at a socket?
--
Cheers -- Tim
--- End Message ---
--- Begin Message ---
On Nov 17, 2011, at 14:03, Tim Streater <t...@clothears.org.uk> wrote:
> I'm playing around with web sockets and have found a couple of simple servers
> written in PHP. They both appear to perform the initial handshake with a
> client but then just give up because socket_recv reports that there is no
> data. I'm confused by this as, the handshake being complete, I wouldn't
> expect there to be any data if the client hasn't sent any. Is there a way to
> wait with timeout on data showing up at a socket?
>
> --
> Cheers -- Tim
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
Any indication if the socket is in blocking mode or not?
--- End Message ---
