#22135 [NEW]: PHP confused by America/Los Angeles timezone

2003-02-08 Thread vaughan
From: [EMAIL PROTECTED]
Operating system: Linux (debian)
PHP version:  4.2.3
PHP Bug Type: Date/time related
Bug description:  PHP confused by America/Los Angeles timezone

\n");
 print("server time is: " . date("F j, Y, g:i a") . "\n");
print("changing server time zone to US/Pacific\n");
putenv("TZ=US/Pacific");
 print("new server time is: " . date("F j, Y, g:i a") . "\n");
print("new server timezone for this script is: " . getenv('TZ'));
?>

The above script gives the following output:

server timezone is: America/Los Angeles
server time is: February 9, 2003, 6:45 am
changing server time zone to US/Pacific
new server time is: February 8, 2003, 10:45 pm
new server timezone for this script is: US/Pacific

the correct date and time in Los Angeles at the time of running the script
is: February 8, 2003, 10:45 pm

The date command on the system gives the correct time and date.

/etc/timezone contains US/Pacific

setting environment variable TZ=US/Pacific before restarting apache has no
effect on the above script. 

PHP configure line:

 './configure' '--with-mysql' '--with-apxs'
'--with-config-file-path=/etc/php4/apache' '--enable-track-vars'
'--enable-trans-sid' '--with-sybase=/usr/local/freetds' '--with-ldap'
'--with-imap' '--with-curl=/usr' '--with-pgsql=/usr/include/postgresql'
'--with-gd' '--with-xml' '--enable-cli'

Apache/1.3.26

Apache modules are: mod_php4, mod_ssl, mod_perl, mod_dav, mod_setenvif,
mod_unique_id, mod_expires, mod_auth, mod_access, mod_rewrite, mod_alias,
mod_userdir, mod_cgi, mod_dir, mod_autoindex, mod_status, mod_negotiation,
mod_mime, mod_log_config, mod_macro, mod_so, http_core

This could be a problem with the underlying debian (2.2.19 kernel) system,
but I thought I should report it.

Thank you.






-- 
Edit bug report at http://bugs.php.net/?id=22135&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22135&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22135&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22135&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22135&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22135&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22135&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22135&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22135&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22135&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22135&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22135&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22135&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22135&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22135&r=gnused




#22135 [Opn]: PHP confused by America/Los Angeles timezone

2003-02-09 Thread vaughan
 ID:   22135
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Date/time related
 Operating System: Linux (debian)
 PHP Version:  4.2.3
 New Comment:

Yes, tzselect suggests that TZ be set as 'America/Los_Angeles'.

I did this, using export TZ='America/Los_Angeles' and restarted apache.
 It made no difference to the php script output. 

In other words, if php believes that the server timezone is
'America/Los_Angeles' it gives the incorrect time.  But if it believes
that timezone is 'US/Pacific' it gives the correct time.  However,
setting TZ to 'US/Pacific' also makes no difference to the script
output.  So I'm wondering where PHP is picking up the timezone
information from and how I can get it to believe that the timezone is
'US/Pacific' from startup.  Can I set that in php.ini?

(Also, there are two timezone commands on debian, tzselect and
tzconfig.  tzconfig lets one choose either 'US/Pacific' or
'America/Los_Angeles' for the timezone, but neither makes a difference
to this script).


Previous Comments:


[2003-02-09 07:49:05] [EMAIL PROTECTED]

Using tzselect on Debian leads to the assumption that your TZ variable
should probably be "America/Los_Angeles" (with underscore). Can you
test that, please?



[2003-02-09 00:56:15] [EMAIL PROTECTED]

\n");
 print("server time is: " . date("F j, Y, g:i a") . "\n");
print("changing server time zone to US/Pacific\n");
putenv("TZ=US/Pacific");
 print("new server time is: " . date("F j, Y, g:i a") . "\n");
print("new server timezone for this script is: " . getenv('TZ'));
?>

The above script gives the following output:

server timezone is: America/Los Angeles
server time is: February 9, 2003, 6:45 am
changing server time zone to US/Pacific
new server time is: February 8, 2003, 10:45 pm
new server timezone for this script is: US/Pacific

the correct date and time in Los Angeles at the time of running the
script is: February 8, 2003, 10:45 pm

The date command on the system gives the correct time and date.

/etc/timezone contains US/Pacific

setting environment variable TZ=US/Pacific before restarting apache has
no effect on the above script. 

PHP configure line:

 './configure' '--with-mysql' '--with-apxs'
'--with-config-file-path=/etc/php4/apache' '--enable-track-vars'
'--enable-trans-sid' '--with-sybase=/usr/local/freetds' '--with-ldap'
'--with-imap' '--with-curl=/usr' '--with-pgsql=/usr/include/postgresql'
'--with-gd' '--with-xml' '--enable-cli'

Apache/1.3.26

Apache modules are: mod_php4, mod_ssl, mod_perl, mod_dav, mod_setenvif,
mod_unique_id, mod_expires, mod_auth, mod_access, mod_rewrite,
mod_alias, mod_userdir, mod_cgi, mod_dir, mod_autoindex, mod_status,
mod_negotiation, mod_mime, mod_log_config, mod_macro, mod_so,
http_core

This could be a problem with the underlying debian (2.2.19 kernel)
system, but I thought I should report it.

Thank you.










-- 
Edit this bug report at http://bugs.php.net/?id=22135&edit=1




#22135 [Opn]: PHP confused by America/Los Angeles timezone

2003-02-09 Thread vaughan
 ID:   22135
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Date/time related
 Operating System: Linux (debian)
 PHP Version:  4.2.3
 New Comment:

here's what I do, as root:

# export TZ='America/Los_Angeles'
# set | grep TZ
# TZ=America/Los_Angeles
# apachectl stop
/usr/sbin/apachectl stop: httpd stopped
# apachectl start
/usr/sbin/apachectl start: httpd started


output of the php script: 

server timezone is: America/Los Angeles
server time is: February 9, 2003, 7:51 pm
changing server time zone to US/Pacific
new server time is: February 9, 2003, 11:51 am
new server timezone for this script is: US/Pacific

I notice that PHP does not pick up the underscore in "Los_Angeles".

What I wondered was whether there's a way to do the equivalent of
putenv("TZ=US/Pacific") in php.ini?

However, I have just noticed that the time is wrong in OTRS running on
the same server -- and it is a set of perl scripts.  So maybe this is
not a PHP bug at all?


Previous Comments:


[2003-02-09 12:39:25] [EMAIL PROTECTED]

"apachectl restart" does not pick up the new TZ environment variable.
Did you try apachectl stop / apachectl start? I get the same results as
you with TZ="America/Los Angeles", but "America/Los_Angeles" or
"US/Pacific" work. As far as I know there's no php.ini setting that
fiddles with timezones.



[2003-02-09 10:54:54] [EMAIL PROTECTED]

Yes, tzselect suggests that TZ be set as 'America/Los_Angeles'.

I did this, using export TZ='America/Los_Angeles' and restarted apache.
 It made no difference to the php script output. 

In other words, if php believes that the server timezone is
'America/Los_Angeles' it gives the incorrect time.  But if it believes
that timezone is 'US/Pacific' it gives the correct time.  However,
setting TZ to 'US/Pacific' also makes no difference to the script
output.  So I'm wondering where PHP is picking up the timezone
information from and how I can get it to believe that the timezone is
'US/Pacific' from startup.  Can I set that in php.ini?

(Also, there are two timezone commands on debian, tzselect and
tzconfig.  tzconfig lets one choose either 'US/Pacific' or
'America/Los_Angeles' for the timezone, but neither makes a difference
to this script).



[2003-02-09 07:49:05] [EMAIL PROTECTED]

Using tzselect on Debian leads to the assumption that your TZ variable
should probably be "America/Los_Angeles" (with underscore). Can you
test that, please?



[2003-02-09 00:56:15] [EMAIL PROTECTED]

\n");
 print("server time is: " . date("F j, Y, g:i a") . "\n");
print("changing server time zone to US/Pacific\n");
putenv("TZ=US/Pacific");
 print("new server time is: " . date("F j, Y, g:i a") . "\n");
print("new server timezone for this script is: " . getenv('TZ'));
?>

The above script gives the following output:

server timezone is: America/Los Angeles
server time is: February 9, 2003, 6:45 am
changing server time zone to US/Pacific
new server time is: February 8, 2003, 10:45 pm
new server timezone for this script is: US/Pacific

the correct date and time in Los Angeles at the time of running the
script is: February 8, 2003, 10:45 pm

The date command on the system gives the correct time and date.

/etc/timezone contains US/Pacific

setting environment variable TZ=US/Pacific before restarting apache has
no effect on the above script. 

PHP configure line:

 './configure' '--with-mysql' '--with-apxs'
'--with-config-file-path=/etc/php4/apache' '--enable-track-vars'
'--enable-trans-sid' '--with-sybase=/usr/local/freetds' '--with-ldap'
'--with-imap' '--with-curl=/usr' '--with-pgsql=/usr/include/postgresql'
'--with-gd' '--with-xml' '--enable-cli'

Apache/1.3.26

Apache modules are: mod_php4, mod_ssl, mod_perl, mod_dav, mod_setenvif,
mod_unique_id, mod_expires, mod_auth, mod_access, mod_rewrite,
mod_alias, mod_userdir, mod_cgi, mod_dir, mod_autoindex, mod_status,
mod_negotiation, mod_mime, mod_log_config, mod_macro, mod_so,
http_core

This could be a problem with the underlying debian (2.2.19 kernel)
system, but I thought I should report it.

Thank you.










-- 
Edit this bug report at http://bugs.php.net/?id=22135&edit=1




#22135 [Opn]: PHP confused by America/Los Angeles timezone

2003-02-22 Thread vaughan at ucla dot edu
 ID:   22135
 User updated by:  vaughan at ucla dot edu
 Reported By:  vaughan at ucla dot edu
 Status:   Open
 Bug Type: Date/time related
 Operating System: Linux (debian)
 PHP Version:  4.2.3
 New Comment:

no, TZ is not being set in httpd.conf nor in apachectl.

Experiment #1
What happens if we use putenv("TZ=US/Los_Angeles")?

the script:

\n");
print("server time is: " . date("F j, Y, g:i a") . "\n");
print("changing server time zone to US/Los_Angeles\n");
putenv("TZ=US/Los_Angeles");
 print("new server time is: " . date("F j, Y, g:i a") . "\n");
print("new server timezone for this script is: " . getenv('TZ'));
?>

here's the output, with the incorrect times:

server timezone is: America/Los Angeles
server time is: February 22, 2003, 5:01 pm
changing server time zone to US/Los_Angeles
new server time is: February 22, 2003, 5:01 pm
new server timezone for this script is: US/Los_Angeles
output of date(T):US/Los_Angeles


Experiment # 2:

I also tried putting 

SetEnv US/Pacific

into httpd.conf.

this script:

 print("server timezone is: " . getenv('TZ') . "\n");
 print("server time is: " . date("F j, Y, g:i a") . "\n");
print("changing server time zone to US/Pacific\n");
putenv("TZ=US/Pacific");
 print("new server time is: " . date("F j, Y, g:i a") . "\n");
print("new server timezone for this script is: " . getenv('TZ'));

produces this output:

server timezone is: US/Pacific
server time is: February 22, 2003, 5:29 pm
changing server time zone to US/Pacific
new server time is: February 22, 2003, 9:29 am
new server timezone for this script is: US/Pacific
output of date(T):PST

In this case, PHP picks up the US/Pacific timezone from the
environment, but gets the time wrong!

Experiment # 3

try with SetEnv = US/Los_Angeles in httpd.conf

same script as #2, produces bad output:

server timezone is: US/Los_Angeles
server time is: February 22, 2003, 5:34 pm
changing server time zone to US/Pacific
new server time is: February 22, 2003, 9:34 am
new server timezone for this script is: US/Los_Angeles
output of date(T):PST

So it seems to be the case that the ONLY way to get PHP to have the
correct time is to use putenv("TZ=US/Pacific") in a script.

Any other ideas?  Thanks for your help


Previous Comments:


[2003-02-09 16:49:25] michael dot mauch at gmx dot de

You don't have a

  SetEnv TZ "America/Los Angeles"

in your httpd.conf, do you? Or maybe TZ is fixed in your apachectl
script?



[2003-02-09 13:54:50] vaughan at ucla dot edu

here's what I do, as root:

# export TZ='America/Los_Angeles'
# set | grep TZ
# TZ=America/Los_Angeles
# apachectl stop
/usr/sbin/apachectl stop: httpd stopped
# apachectl start
/usr/sbin/apachectl start: httpd started


output of the php script: 

server timezone is: America/Los Angeles
server time is: February 9, 2003, 7:51 pm
changing server time zone to US/Pacific
new server time is: February 9, 2003, 11:51 am
new server timezone for this script is: US/Pacific

I notice that PHP does not pick up the underscore in "Los_Angeles".

What I wondered was whether there's a way to do the equivalent of
putenv("TZ=US/Pacific") in php.ini?

However, I have just noticed that the time is wrong in OTRS running on
the same server -- and it is a set of perl scripts.  So maybe this is
not a PHP bug at all?



[2003-02-09 12:39:25] michael dot mauch at gmx dot de

"apachectl restart" does not pick up the new TZ environment variable.
Did you try apachectl stop / apachectl start? I get the same results as
you with TZ="America/Los Angeles", but "America/Los_Angeles" or
"US/Pacific" work. As far as I know there's no php.ini setting that
fiddles with timezones.



[2003-02-09 10:54:54] vaughan at ucla dot edu

Yes, tzselect suggests that TZ be set as 'America/Los_Angeles'.

I did this, using export TZ='America/Los_Angeles' and restarted apache.
 It made no difference to the php script output. 

In other words, if php believes that the server timezone is
'America/Los_Angeles' it gives the incorrect time.  But if it believes
that timezone is 'US/Pacific' it gives the correct time.  However,
setting TZ to 'US/Pacific' also makes no difference to the script
output.  So I'm wondering where PHP is picking up the timezone
information from and how I

#22135 [Opn]: PHP confused by America/Los Angeles timezone

2003-02-24 Thread vaughan at ucla dot edu
 ID:   22135
 User updated by:  vaughan at ucla dot edu
 Reported By:  vaughan at ucla dot edu
 Status:   Open
 Bug Type: Date/time related
 Operating System: Linux (debian)
 PHP Version:  4.2.3
 New Comment:

You're right. I should have used "America/Los_Angeles".

results: experiment #1, using
 putenv("TZ=America/Los_Angeles");

php produces the correct time after this, but not before (that is,
doesn't pick up TZ from the system).

experiment # 3, SetEnv TZ=America/Los_Angeles in httpd.conf
has no effect -- the time is still wrong until I use putenv with either
"US/Pacific" or "America/Los_Angeles".


Previous Comments:


[2003-02-22 13:37:46] michael dot mauch at gmx dot de

I don't see a /usr/share/zoneinfo/US/Los_Angeles on Debian, only
America/Los_Angeles (and US/Pacific). So I suggest you try again with
America/Los_Angeles.

----

[2003-02-22 11:37:58] vaughan at ucla dot edu

no, TZ is not being set in httpd.conf nor in apachectl.

Experiment #1
What happens if we use putenv("TZ=US/Los_Angeles")?

the script:

\n");
print("server time is: " . date("F j, Y, g:i a") . "\n");
print("changing server time zone to US/Los_Angeles\n");
putenv("TZ=US/Los_Angeles");
 print("new server time is: " . date("F j, Y, g:i a") . "\n");
print("new server timezone for this script is: " . getenv('TZ'));
?>

here's the output, with the incorrect times:

server timezone is: America/Los Angeles
server time is: February 22, 2003, 5:01 pm
changing server time zone to US/Los_Angeles
new server time is: February 22, 2003, 5:01 pm
new server timezone for this script is: US/Los_Angeles
output of date(T):US/Los_Angeles


Experiment # 2:

I also tried putting 

SetEnv US/Pacific

into httpd.conf.

this script:

 print("server timezone is: " . getenv('TZ') . "\n");
 print("server time is: " . date("F j, Y, g:i a") . "\n");
print("changing server time zone to US/Pacific\n");
putenv("TZ=US/Pacific");
 print("new server time is: " . date("F j, Y, g:i a") . "\n");
print("new server timezone for this script is: " . getenv('TZ'));

produces this output:

server timezone is: US/Pacific
server time is: February 22, 2003, 5:29 pm
changing server time zone to US/Pacific
new server time is: February 22, 2003, 9:29 am
new server timezone for this script is: US/Pacific
output of date(T):PST

In this case, PHP picks up the US/Pacific timezone from the
environment, but gets the time wrong!

Experiment # 3

try with SetEnv = US/Los_Angeles in httpd.conf

same script as #2, produces bad output:

server timezone is: US/Los_Angeles
server time is: February 22, 2003, 5:34 pm
changing server time zone to US/Pacific
new server time is: February 22, 2003, 9:34 am
new server timezone for this script is: US/Los_Angeles
output of date(T):PST

So it seems to be the case that the ONLY way to get PHP to have the
correct time is to use putenv("TZ=US/Pacific") in a script.

Any other ideas?  Thanks for your help

----

[2003-02-09 16:49:25] michael dot mauch at gmx dot de

You don't have a

  SetEnv TZ "America/Los Angeles"

in your httpd.conf, do you? Or maybe TZ is fixed in your apachectl
script?



[2003-02-09 13:54:50] vaughan at ucla dot edu

here's what I do, as root:

# export TZ='America/Los_Angeles'
# set | grep TZ
# TZ=America/Los_Angeles
# apachectl stop
/usr/sbin/apachectl stop: httpd stopped
# apachectl start
/usr/sbin/apachectl start: httpd started


output of the php script: 

server timezone is: America/Los Angeles
server time is: February 9, 2003, 7:51 pm
changing server time zone to US/Pacific
new server time is: February 9, 2003, 11:51 am
new server timezone for this script is: US/Pacific

I notice that PHP does not pick up the underscore in "Los_Angeles".

What I wondered was whether there's a way to do the equivalent of
putenv("TZ=US/Pacific") in php.ini?

However, I have just noticed that the time is wrong in OTRS running on
the same server -- and it is a set of perl scripts.  So maybe this is
not a PHP bug at all?



[2003-02-09 12:39:25] michael dot mauch at gmx dot de

"apachectl restart" does not pick up the new TZ environment variable.
Did you try apachectl stop / apachectl start? I get the same results as
you with TZ="America/Los Angeles"

#22135 [Fbk->Opn]: PHP confused by America/Los Angeles timezone

2003-02-25 Thread vaughan at ucla dot edu
 ID:   22135
 User updated by:  vaughan at ucla dot edu
 Reported By:  vaughan at ucla dot edu
-Status:   Feedback
+Status:   Open
 Bug Type: Date/time related
 Operating System: Linux (debian)
 PHP Version:  4.2.3
 New Comment:

[EMAIL PROTECTED] wrote:

You should set the timezone correctly before you _start_
apache, in the shell..

I tried that..see my posting below from 9 Feb 1:54pm. Even when TZ is
set correctly in the shell to 'America/Los_Angeles' before starting
apache, php's getenv('TZ') reports "America/Los Angeles" as the
timezone. If I set TZ to 'US/Pacific' in the shell, stop and start
apache, php still reports the timezone incorrectly as "America/Los
Angeles".  So, if PHP does not seem to be picking up the timezone from
the environment.  Again, the only way I can affect the timezone is
using putenv(). 

Not sure where to go from here.  Perhaps pull from CVS and recompile?


Previous Comments:


[2003-02-25 02:27:31] [EMAIL PROTECTED]

As your first script mentioned, the output for
getenv('TZ') was "America/Los Angeles" which is wrong..




[2003-02-25 02:26:31] [EMAIL PROTECTED]

SetEnv in httpd.conf has no effect on PHP.
You should set the timezone correctly before you _start_
apache, in the shell..



----

[2003-02-24 10:38:00] vaughan at ucla dot edu

You're right. I should have used "America/Los_Angeles".

results: experiment #1, using
 putenv("TZ=America/Los_Angeles");

php produces the correct time after this, but not before (that is,
doesn't pick up TZ from the system).

experiment # 3, SetEnv TZ=America/Los_Angeles in httpd.conf
has no effect -- the time is still wrong until I use putenv with either
"US/Pacific" or "America/Los_Angeles".



[2003-02-22 13:37:46] michael dot mauch at gmx dot de

I don't see a /usr/share/zoneinfo/US/Los_Angeles on Debian, only
America/Los_Angeles (and US/Pacific). So I suggest you try again with
America/Los_Angeles.



[2003-02-22 11:37:58] vaughan at ucla dot edu

no, TZ is not being set in httpd.conf nor in apachectl.

Experiment #1
What happens if we use putenv("TZ=US/Los_Angeles")?

the script:

\n");
print("server time is: " . date("F j, Y, g:i a") . "\n");
print("changing server time zone to US/Los_Angeles\n");
putenv("TZ=US/Los_Angeles");
 print("new server time is: " . date("F j, Y, g:i a") . "\n");
print("new server timezone for this script is: " . getenv('TZ'));
?>

here's the output, with the incorrect times:

server timezone is: America/Los Angeles
server time is: February 22, 2003, 5:01 pm
changing server time zone to US/Los_Angeles
new server time is: February 22, 2003, 5:01 pm
new server timezone for this script is: US/Los_Angeles
output of date(T):US/Los_Angeles


Experiment # 2:

I also tried putting 

SetEnv US/Pacific

into httpd.conf.

this script:

 print("server timezone is: " . getenv('TZ') . "\n");
 print("server time is: " . date("F j, Y, g:i a") . "\n");
print("changing server time zone to US/Pacific\n");
putenv("TZ=US/Pacific");
 print("new server time is: " . date("F j, Y, g:i a") . "\n");
print("new server timezone for this script is: " . getenv('TZ'));

produces this output:

server timezone is: US/Pacific
server time is: February 22, 2003, 5:29 pm
changing server time zone to US/Pacific
new server time is: February 22, 2003, 9:29 am
new server timezone for this script is: US/Pacific
output of date(T):PST

In this case, PHP picks up the US/Pacific timezone from the
environment, but gets the time wrong!

Experiment # 3

try with SetEnv = US/Los_Angeles in httpd.conf

same script as #2, produces bad output:

server timezone is: US/Los_Angeles
server time is: February 22, 2003, 5:34 pm
changing server time zone to US/Pacific
new server time is: February 22, 2003, 9:34 am
new server timezone for this script is: US/Los_Angeles
output of date(T):PST

So it seems to be the case that the ONLY way to get PHP to have the
correct time is to use putenv("TZ=US/Pacific") in a script.

Any other ideas?  Thanks for your help



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/22135

-- 
Edit this bug report at http://bugs.php.net/?id=22135&edit=1



#29236 [NEW]: memory error when wsdl-cache is enabled

2004-07-17 Thread vaughan at ucla dot edu
From: vaughan at ucla dot edu
Operating system: debian linux 2.4.26
PHP version:  5CVS-2004-07-18 (dev)
PHP Bug Type: SOAP related
Bug description:  memory error when wsdl-cache is enabled

Description:

perhaps related to bug # 27994 and 29109?

all wsdl urls seem to work on first access. For some, 
the second access causes a memory error: browser returns 
nothing, but the error log contains:

FATAL:  emalloc():  Unable to allocate -2080374783 bytes

but other wsdl urls work fine all the time.  

for example, http://services.xmethods.net/soap/urn:
xmethods-delayed-quotes.wsdl works fine, but this one 
(which is the one I'm interested in!) causes the error:

http://isisdev1.tig.ucla.edu/iws/v4.asmx?WSDL

The only difference I can see is the size of the wsdl 
cache file:

 ls -la /tmp/wsdl* 
-rw-r--r--1 www-data www-data  655 Jul 17 18:45 
/tmp/wsdl-1d3ed057f34bf52d1ef18dd2d2cf17b0
-rw-r--r--1 www-data www-data11616 Jul 17 18:45 
/tmp/wsdl-7a407628dfa2fa2c7282f12e23774f98

If I remove the big one, then the code below works 
again, but only once.


Reproduce code:
---
http://isisdev1.tig.ucla.edu/iws/v4.asmx?WSDL";;

$client = new SoapClient($endpoint);

echo "";
var_dump($client->__getFunctions()); 
echo "";

?>

Expected result:

On first run, when there's no wsdl cache file, I get the 
expected list of functions.

Actual result:
--
no browser output

emalloc error recorded in log file.

-- 
Edit bug report at http://bugs.php.net/?id=29236&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=29236&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=29236&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=29236&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=29236&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29236&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=29236&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=29236&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=29236&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=29236&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=29236&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=29236&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=29236&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29236&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=29236&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=29236&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=29236&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29236&r=float


Bug #50431 [Com]: Using filter_var to filter an email address returns incorrect result

2010-12-19 Thread vaughan dot montgomery at gmail dot com
Edit report at http://bugs.php.net/bug.php?id=50431&edit=1

 ID: 50431
 Comment by: vaughan dot montgomery at gmail dot com
 Reported by:troy at scriptedmotion dot com
 Summary:Using filter_var to filter an email address returns
 incorrect result
 Status: Bogus
 Type:   Bug
 Package:Filter related
 Operating System:   Ubuntu
 PHP Version:5.2.11
 Block user comment: N
 Private report: N

 New Comment:

ok you say that's a valid email.. but in a working user environment,
using this 

filter to VALIDATE an email address is unworkable.



when users register on my site, i want to validate their email address.



if the user enters t...@test, it returns as valid. but how on earth does
my 

server know that the users email address .com/.net/.co.uk/.biz etc. so
when it 

tries to send the user an email to validate his email address in order
to 

register on my site, he never receives the email because the server
doesn't know 

where to send it.



this means i can't use this filter for its intended purpose of
validating an 

email address.



back to using regex and the old PHP 4 methods.



either make the filter return as invalid, or add an extra parameter to
tell it 

to validate with a top level domain.



ie. filter_var('t...@test', FILTER_VALIDATE_EMAIL, FILTER_FLAG_TOP_LEVEL)



if FILTER_FLAG_TOP_LEVEL is set, then 't...@test' returns invalid, if
not, then 

return valid.



problem solved, and i'm sure many users would apreciate it.


Previous Comments:

[2010-08-20 16:53:27] michael at squiloople dot com

The standards are actually RFC 5321 and 5322, and according to RFC 5321
(which 

goes into more specific detail over domain names in email addresses),
"in the case 

of a top-level domain used by itself in an email address, a single
string is used 

without any dots."


[2010-05-08 02:32:01] office at lucian0308 dot com

i see a deference 

the standard is http://tools.ietf.org/html/rfc2822



this function respect the standard?



because PEAR
http://pear.php.net/manual/en/package.validate.validate.email.php

say that use RFC2822 and it works corectly 



without  dot and level domain shoud be a false email.


[2009-12-09 19:02:01] ras...@php.net

That's a valid email address.  Email addresses don't need a tld.  Try 

emailing r...@localhost, for example.  Any locally defined host can 

potentially receive email.


[2009-12-09 18:59:19] troy at scriptedmotion dot com

Description:

Using filter_var to filter a string containing an email address with no
top level domain returns the string instead of false.



For example:



filter_var('t...@1', FILTER_VALIDATE_EMAIL);



returns 't...@1' instead of false.

Reproduce code:
---
filter_var('t...@1', FILTER_VALIDATE_EMAIL); // returns 't...@1' instead of
false.

Expected result:

false

Actual result:
--
"t...@1" // a string






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=50431&edit=1


Bug #50431 [Com]: Using filter_var to filter an email address returns incorrect result

2010-12-20 Thread vaughan dot montgomery at gmail dot com
Edit report at http://bugs.php.net/bug.php?id=50431&edit=1

 ID: 50431
 Comment by: vaughan dot montgomery at gmail dot com
 Reported by:troy at scriptedmotion dot com
 Summary:Using filter_var to filter an email address returns
 incorrect result
 Status: Bogus
 Type:   Bug
 Package:Filter related
 Operating System:   Ubuntu
 PHP Version:5.2.11
 Block user comment: N
 Private report: N

 New Comment:

that's true. but in the real world! we aren't dealing with local issues.
yes 

t...@localhost is valid for local, but it's no good on a remote server.
i want 

my users to have to enter their address as t...@test.com or .co.uk or
whatever, 

like everyone else out there who wants to use this filter for validating
user 

email addresses. why is this so difficult to get through? what is so
wrong with 

changing it or adding a filter flag to the filter for top level domains
etc? 

then we have the best of both worlds.



if you won't do something about it, then this filter is pretty much
useless to 

many people, i would have preferred to use it, but will have to stick to
using 

the cumbersome regex method instead.


Previous Comments:

[2010-12-20 19:56:52] ras...@php.net

Even if he enters t...@test.com that still doesn't tell you if the email
will get 

through to him.  You are in the same position.  The filter simply
validates the 

string as a valid-looking email address.  Whether or not this is the
actual user's 

email address is way beyond the scope of this function.  You can take it
further 

and do an MX lookup on it, but that just means the host exists, it
doesn't mean 

that user has an account on that box.  The only way to know is to
actually deliver 

an email to the address and see if the user gets it.

----
[2010-12-20 02:02:29] vaughan dot montgomery at gmail dot com

ok you say that's a valid email.. but in a working user environment,
using this 

filter to VALIDATE an email address is unworkable.



when users register on my site, i want to validate their email address.



if the user enters t...@test, it returns as valid. but how on earth does
my 

server know that the users email address .com/.net/.co.uk/.biz etc. so
when it 

tries to send the user an email to validate his email address in order
to 

register on my site, he never receives the email because the server
doesn't know 

where to send it.



this means i can't use this filter for its intended purpose of
validating an 

email address.



back to using regex and the old PHP 4 methods.



either make the filter return as invalid, or add an extra parameter to
tell it 

to validate with a top level domain.



ie. filter_var('t...@test', FILTER_VALIDATE_EMAIL, FILTER_FLAG_TOP_LEVEL)



if FILTER_FLAG_TOP_LEVEL is set, then 't...@test' returns invalid, if
not, then 

return valid.



problem solved, and i'm sure many users would apreciate it.


[2010-08-20 16:53:27] michael at squiloople dot com

The standards are actually RFC 5321 and 5322, and according to RFC 5321
(which 

goes into more specific detail over domain names in email addresses),
"in the case 

of a top-level domain used by itself in an email address, a single
string is used 

without any dots."


[2010-05-08 02:32:01] office at lucian0308 dot com

i see a deference 

the standard is http://tools.ietf.org/html/rfc2822



this function respect the standard?



because PEAR
http://pear.php.net/manual/en/package.validate.validate.email.php

say that use RFC2822 and it works corectly 



without  dot and level domain shoud be a false email.


[2009-12-09 19:02:01] ras...@php.net

That's a valid email address.  Email addresses don't need a tld.  Try 

emailing r...@localhost, for example.  Any locally defined host can 

potentially receive email.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

http://bugs.php.net/bug.php?id=50431


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=50431&edit=1


#25639 [Com]: problem with rand()

2003-10-08 Thread paul dot vaughan at weston dot ac dot uk
 ID:   25639
 Comment by:   paul dot vaughan at weston dot ac dot uk
 Reported By:  adamm at nycap dot rr dot com
 Status:   No Feedback
 Bug Type: Scripting Engine problem
 Operating System: windows
 PHP Version:  4.3.3
 New Comment:

I was having this problem (PHP 4.3.3 on WinNT 4) but in response to
[EMAIL PROTECTED]'s question, the function 'srand()' does indeed fix the
problem.

The code:
for ($j=1; $j<10001; $j++) {
   print (rand(0, $j)."");
}
...produced the same ten thousand random numbers each and every time.
Putting srand() before the loop stopped this happening.

I hope this info is useful to someone; not sure anyone will read
this...!

Vaughany.


Previous Comments:


[2003-09-29 05:55:49] [EMAIL PROTECTED]

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.





[2003-09-23 22:29:00] [EMAIL PROTECTED]

Does this happen if you call srand() prior to calling the rand()
function?



[2003-09-23 18:37:38] adamm at nycap dot rr dot com

I downgraded to 4.3.2 and I dont have this problem. I also found
several posts on the net about many people on Win XP having this
problem with 4.3.3.

Definate bug id say.



[2003-09-23 18:21:40] adamm at nycap dot rr dot com

Description:

I am developing on a newly setup Windows XP Box running PHP 4.3.3 on
IIS as CGI.

The rand() function is not generating random numbers. Even with a
min/max declared it will only once generate a number in that range...
and than any other time called (even across browser sessions) it will
always and forever generate the same number.

The code below is broken down to the smallest example possible.

Reproduce code:
---


Expected result:

I expect to see a random number.

Actual result:
--
The same number is always displayed.





-- 
Edit this bug report at http://bugs.php.net/?id=25639&edit=1