[PHP-DOC] #22198 [Ana]: date() returning incorrect date
ID: 22198 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Documentation problem Operating System: Solaris 8 (sparc) PHP Version: 4.3.0 New Comment: $ zdump -v "Europe/Lisbon" | grep 2003 Europe/Lisbon Sun Mar 30 00:59:59 2003 UTC = Sun Mar 30 00:59:59 2003 WET isdst =0 gmtoff=0 Europe/Lisbon Sun Mar 30 01:00:00 2003 UTC = Sun Mar 30 02:00:00 2003 WEST isds t=1 gmtoff=3600 Europe/Lisbon Sun Oct 26 00:59:59 2003 UTC = Sun Oct 26 01:59:59 2003 WEST isds t=1 gmtoff=3600 Europe/Lisbon Sun Oct 26 01:00:00 2003 UTC = Sun Oct 26 01:00:00 2003 WET isdst =0 gmtoff=0 $ Previous Comments: [2003-02-13 14:43:22] [EMAIL PROTECTED] Out of curiosity: can you please check the TZ environment variable on your machines and perhaps also the output of zdump -v "$TZ" | grep 2003 On Linux, I get: # zdump -v "Europe/Lisbon" | grep 2003 Europe/Lisbon Sun Mar 30 00:59:59 2003 UTC = Sun Mar 30 00:59:59 2003 WET isdst=0 gmtoff=0 Europe/Lisbon Sun Mar 30 01:00:00 2003 UTC = Sun Mar 30 02:00:00 2003 WEST isdst=1 gmtoff=3600 Europe/Lisbon Sun Oct 26 00:59:59 2003 UTC = Sun Oct 26 01:59:59 2003 WEST isdst=1 gmtoff=3600 Europe/Lisbon Sun Oct 26 01:00:00 2003 UTC = Sun Oct 26 01:00:00 2003 WET isdst=0 gmtoff=0 [2003-02-12 22:22:17] [EMAIL PROTECTED] Setting is_dst to 0 *solves* it for solaris. Curiously though, it totally brakes for freebsd between 1-2AM. setting is_dst (either with the default -1 or with 0 or 1) in freebsd outputs: ... (0 h, 59 m, 58 s) 1048985998 --> 30/03/2003 (0 h, 59 m, 59 s) 1048985999 --> 30/03/2003 (1 h, 0 m, 0 s) -1 --> 01/01/1970 (1 h, 0 m, 1 s) -1 --> 01/01/1970 ... (1 h, 59 m, 58 s) -1 --> 01/01/1970 (1 h, 59 m, 59 s) -1 --> 01/01/1970 (2 h, 0 m, 0 s) 1048986000 --> 30/03/2003 (2 h, 0 m, 1 s) 1048986001 --> 30/03/2003 ... [2003-02-12 21:56:14] [EMAIL PROTECTED] btw. mktime() has 7th optional parameter 'is_dst'. When I use your example script, and set that to 1, I get same results as you. >From manual page for mktime: "is_dst can be set to 1 if the time is during daylight savings time, 0 if it is not, or -1 (the default) if it is unknown whether the time is within daylight savings time or not. If it's unknown, PHP tries to figure it out itself. This can cause unexpected (but not incorrect) results. " Try setting that to 0. [2003-02-12 21:51:14] [EMAIL PROTECTED] Yes, it was what I suspected. On Linux, the same script gives 30/03/2003 from the 00:00:00 time til the end. We need to document this behaviour a bit better.. (never use 00:00:00 as time!) [2003-02-12 21:47:17] [EMAIL PROTECTED] script: $frm2\n"; } } } ?> relevant part of output: ... (0 h, 59 m, 55 s) 1048982395 --> 29/03/2003 (0 h, 59 m, 56 s) 1048982396 --> 29/03/2003 (0 h, 59 m, 57 s) 1048982397 --> 29/03/2003 (0 h, 59 m, 58 s) 1048982398 --> 29/03/2003 (0 h, 59 m, 59 s) 1048982399 --> 29/03/2003 (1 h, 0 m, 0 s) 1048982400 --> 30/03/2003 (1 h, 0 m, 1 s) 1048982401 --> 30/03/2003 (1 h, 0 m, 2 s) 1048982402 --> 30/03/2003 (1 h, 0 m, 3 s) 1048982403 --> 30/03/2003 (1 h, 0 m, 4 s) 1048982404 --> 30/03/2003 ... 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/22198 -- Edit this bug report at http://bugs.php.net/?id=22198&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #22198 [Ana]: date() returning incorrect date
ID: 22198 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Documentation problem Operating System: Solaris 8 (sparc) PHP Version: 4.3.0 New Comment: Setting is_dst to 0 *solves* it for solaris. Curiously though, it totally brakes for freebsd between 1-2AM. setting is_dst (either with the default -1 or with 0 or 1) in freebsd outputs: ... (0 h, 59 m, 58 s) 1048985998 --> 30/03/2003 (0 h, 59 m, 59 s) 1048985999 --> 30/03/2003 (1 h, 0 m, 0 s) -1 --> 01/01/1970 (1 h, 0 m, 1 s) -1 --> 01/01/1970 ... (1 h, 59 m, 58 s) -1 --> 01/01/1970 (1 h, 59 m, 59 s) -1 --> 01/01/1970 (2 h, 0 m, 0 s) 1048986000 --> 30/03/2003 (2 h, 0 m, 1 s) 1048986001 --> 30/03/2003 ... Previous Comments: [2003-02-12 21:56:14] [EMAIL PROTECTED] btw. mktime() has 7th optional parameter 'is_dst'. When I use your example script, and set that to 1, I get same results as you. >From manual page for mktime: "is_dst can be set to 1 if the time is during daylight savings time, 0 if it is not, or -1 (the default) if it is unknown whether the time is within daylight savings time or not. If it's unknown, PHP tries to figure it out itself. This can cause unexpected (but not incorrect) results. " Try setting that to 0. [2003-02-12 21:51:14] [EMAIL PROTECTED] Yes, it was what I suspected. On Linux, the same script gives 30/03/2003 from the 00:00:00 time til the end. We need to document this behaviour a bit better.. (never use 00:00:00 as time!) [2003-02-12 21:47:17] [EMAIL PROTECTED] script: $frm2\n"; } } } ?> relevant part of output: ... (0 h, 59 m, 55 s) 1048982395 --> 29/03/2003 (0 h, 59 m, 56 s) 1048982396 --> 29/03/2003 (0 h, 59 m, 57 s) 1048982397 --> 29/03/2003 (0 h, 59 m, 58 s) 1048982398 --> 29/03/2003 (0 h, 59 m, 59 s) 1048982399 --> 29/03/2003 (1 h, 0 m, 0 s) 1048982400 --> 30/03/2003 (1 h, 0 m, 1 s) 1048982401 --> 30/03/2003 (1 h, 0 m, 2 s) 1048982402 --> 30/03/2003 (1 h, 0 m, 3 s) 1048982403 --> 30/03/2003 (1 h, 0 m, 4 s) 1048982404 --> 30/03/2003 ... [2003-02-12 21:30:23] [EMAIL PROTECTED] Try using some other time that midnight. Some systems tend to behave a bit differently during the dst change and in those systems, the hour between 00:00 - 01:00 doesn't exist..(e.g. Macosx does the same) [2003-02-12 21:07:03] [EMAIL PROTECTED] = TIME END 2003-02-13 03:02:41 = TEST RESULT SUMMARY - Exts skipped: 76 Exts tested : 14 - Number of tests : 443 Tests skipped : 221 (49.9%) Tests failed:3 ( 0.7%) Tests passed: 219 (49.4%) - Time taken : 111 seconds = = FAILED TEST SUMMARY - Error message handling [tests/run-test/test005.phpt] Bug #21131: fopen($filename, "a+") has broken position [ext/standard/tests/file/bug21131.phpt] strtotime() function [ext/standard/tests/time/002.phpt] = 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/22198 -- Edit this bug report at http://bugs.php.net/?id=22198&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] Bug #14424 Updated: is_readable returns error if file does not exist.
ID: 14424 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Suse linux 7.2 PHP Version: 4.1.0 New Comment: So that is what you call downwards compatible? I build a site under 4.0.6, it works fine. There is an update to PHP, my sites break. Previous Comments: [2001-12-12 06:40:15] [EMAIL PROTECTED] So what's the problem? is_readable now returns an error, which is IMHO fine. The only problem is that it's not documented. Changing to docu prob. [2001-12-11 08:22:39] [EMAIL PROTECTED] Code example: if (is_readable("foo")) { echo "file exists."; } else { echo "file does not exist."; } Error message: Warning: stat failed for foo (errno=2 - No such file or directory) in /home/xxx/public_html/is_readable.php on line 3 Configure options: ./configure --with-apache=/home/xxx/apache_1.3.22 --with-mysql=/usr/local --with-gd=/usr/local --with-zlib-dir=/usr/local --with-png-dir=/usr --with-jpeg-dir=/home/xxx/jpeg-6b --with-xpm-dir=/usr/X11R6 --with-ttf --with-curl Seems similar to is_file() bug. Problem does not occur on older versions (i.e. 4.0.6). Edit this bug report at http://bugs.php.net/?id=14424&edit=1