On 12/20/2011 06:09 PM, Will Fitch wrote:
Hello All,
I would like to submit https://wiki.php.net/rfc/returntypehint2 into
discussion. A link to the patch for this is provided and can be ran against
the current HEAD.
There is an older entry still in existence, but this patch is syntacticall
Hello All,
I would like to submit https://wiki.php.net/rfc/returntypehint2 into
discussion. A link to the patch for this is provided and can be ran against
the current HEAD.
There is an older entry still in existence, but this patch is syntactically
different. The older entry is located at
> This can never be portable, because Windows doesn't even bother keeping
> historical timezone rules. They only have: current normal UTC offset,
> current DST offset and rules on when there is a transition between.
Windows does keep historical timezone rules and uses them in
SystemTimeToTzSpecif
My bad, replied only to sender. Fixing it now.
Well, any time you need to know signature or another information about
a function or class method, you should use Reflection. func_num_args()
is useful for when you need a dynamic function, like this (an
hypothetic example using func_get_args(), but y
Hi,
The function func_num_args() doesn't accept any parameters, so calling
func_num_args($oClosure) is the same as calling simple func_num_args(). That's
why it returns 1 instead of 2, which is I think the expected and correct
behavior.
Gergo Erdosi
On Dec 21, 2011, at 24:43 , Mark wrote:
>
func_num_args() must be called inside the Closure to know the number
of arguments that it received. If you are calling outside, it returns
the number of arguments of your testClosure function. There is no
other way than Reflection to do this.
And, I think func_num_args() does not receive any para
Hi,
Why is func_num_args not working on closures?
Example code (tested on PHP 5.3.8):
';
print_r(func_num_args($oClosure));
echo '';
}
}
$c = new Test();
$c->testClosure(function($arg1, $arg2){
});
That returns 1 (the num of args in which function the closure is
(testClosure), but not the numb
On 12/21/2011 03:37 AM, jpauli wrote:
> I guess constant array would mean that all the variables inside the array
> dimensions should not change.
> Just saying that, is a nonsense.
>
> If a constant could be an array, then that array could not contain
> variables, if not it wouldn't be constant any
Hi!
This can never be portable, because Windows doesn't even bother keeping
historical timezone rules. They only have: current normal UTC offset,
current DST offset and rules on when there is a transition between.
Well, that closes the question for Windows, but in theory we maybe could
suppor
I guess constant array would mean that all the variables inside the array
dimensions should not change.
Just saying that, is a nonsense.
If a constant could be an array, then that array could not contain
variables, if not it wouldn't be constant any more as a change to one
variable inside it would
Derick Rethans wrote:
> Actually that is probably another discussion, but is the php date function
> still limited to 13 Dec 1901?
No. Internally, it uses 64 bit integers. As long as you use the object
oriented approach it will work. If you go back to timestamps, you have
to rely on what the
On Thu, 15 Dec 2011, Lester Caine wrote:
> Oleg Oshmyan wrote:
> > It is worth mentioning that VC9 has 64-bit and 32-bit versions of time_t,
> > localtime and mktime while VC6 only has a 32-bit version. Unfortunately,
> > none of these versions work with times before 1970.
>
> Actually that is pr
> It means that they have a crap patch that scans the file system... and
> destroys some information that PHP users need to be able to rely on.
Just as PHP users need to rely on the Olson database being present and usable,
they need to rely on the system time zone being present and usable, but P
On Wed, 14 Dec 2011, Ángel González wrote:
> On 14/12/11 22:53, Will Fitch wrote:
>
> > I believe he's referring to sys/time.h, but this introduces
> > portability issues. If it were just unix, that would be one thing.
> > But maintaining this and a Windows alternative, and I have no idea
> >
On Wed, 14 Dec 2011, Stas Malyshev wrote:
> > I believe he's referring to sys/time.h, but this introduces
> > portability issues. If it were just unix, that would be one thing.
> > But maintaining this and a Windows alternative, and I have no idea
> > what that is, is not worth it IMO.
>
> Ye
On Wed, 14 Dec 2011, Oleg Oshmyan wrote:
> > Using the information from /etc/localtime is *not* enough as
> > you can't get the timezone identifier out of it.
>
> The time zone identifier would be System. No need to extract one from
> /etc/localtime.
"System" is not a defined Timezone Identifi
On Tue, 20 Dec 2011, David Muir wrote:
> Keeping the tz database up to date is a very annoying issue. System tz
> data is typically more up-to-date as it's pushed to the user, while with
> php, you need to have admin rights to install an updated tz database, or
> hope that the packager for your di
On Tue, Dec 20, 2011 at 1:35 AM, David Muir wrote:
> Isn't this whole thread about client-side apps, not server-side. For
> client-side stuff it doesn't make sense to use anything but the system
> tz.
No, that's the job of the PHP application to take care of that. And
that's also why system TZ
18 matches
Mail list logo
