#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