#22135 [NEW]: PHP confused by America/Los Angeles timezone
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
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
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
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
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
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
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
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
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()
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
