[PHP-DEV] PHP 4.0 Bug #9878: gmmktime is 1 hour off during standard time
From: [EMAIL PROTECTED]
Operating system: Solaris 2.6
PHP version: 4.0.4pl1
PHP Bug Type: Date/time related
Bug description: gmmktime is 1 hour off during standard time
gmmktime is producing a timestamp 1 hour off when the timezone is standard time. If
you compare a
time() with gmmktime with current settings and a is_dst
value NULL, the results will be one hour off.
I used the following little script to prove this:
?
print ("PRE");
print ("Time function = ".time ());
print ("\n");
print ("gmmktime = ".gmmktime (18,25,0,3,20,2001));
print ("\n");
print ("mktime = ".mktime(12,25,0,3,20,2001));
print ("\n");
print (gmmktime(7,0,0,4,1,2001)." ".mktime(1,0,0,4,1,2001)."\n");
print (gmmktime(8,0,0,4,1,2001)." ".mktime(3,0,0,4,1,2001)."\n");
?
Currently, the US/Central timezone is -6 hours from GMT.
I believe the problem is in ext/standard/datetime.c, line
186. Judging from the code, "timezone" seems to be a negative seconds value from GMT,
probably of the standard timezone (TZ in standard). So if is_dst == 0, you don't want
to add anything more. I think the like should say:
gmadjust = -(is_dst ? timezone - 3600 : timezone );
And the comment about overcorrecting removed.
My test script works if this line is changed.
--
Edit Bug report at: http://bugs.php.net/?id=9878edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9878 Updated: gmmktime is 1 hour off during standard time
ID: 9878
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Date/time related
Description: gmmktime is 1 hour off during standard time
I know there are a lot of open bugs and this one is probably pretty small compared to
most, but the time window to
easily verify this bug and my suggested fix is quickly going
away for 6 months. With the time shift this weekend, it
wil be much more difficult to reproduce this bug, unless you
start subtracting 86400 seconds per day to get back into standard time.
If someone could just look at what I've provided I think
it will be a no-brainer. Even if it doesn't get tagged into
the new release, at least it will saved for the next.
Thanks
Previous Comments:
---
[2001-03-20 14:08:09] [EMAIL PROTECTED]
gmmktime is producing a timestamp 1 hour off when the timezone is standard time. If
you compare a
time() with gmmktime with current settings and a is_dst
value NULL, the results will be one hour off.
I used the following little script to prove this:
?
print ("PRE");
print ("Time function = ".time ());
print ("n");
print ("gmmktime = ".gmmktime (18,25,0,3,20,2001));
print ("n");
print ("mktime = ".mktime(12,25,0,3,20,2001));
print ("n");
print (gmmktime(7,0,0,4,1,2001)." ".mktime(1,0,0,4,1,2001)."n");
print (gmmktime(8,0,0,4,1,2001)." ".mktime(3,0,0,4,1,2001)."n");
?
Currently, the US/Central timezone is -6 hours from GMT.
I believe the problem is in ext/standard/datetime.c, line
186. Judging from the code, "timezone" seems to be a negative seconds value from GMT,
probably of the standard timezone (TZ in standard). So if is_dst == 0, you don't want
to add anything more. I think the like should say:
gmadjust = -(is_dst ? timezone - 3600 : timezone );
And the comment about overcorrecting removed.
My test script works if this line is changed.
---
Full Bug description available at: http://bugs.php.net/?id=9878
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10448 Updated: PHP core dumps after array_init
ID: 10448 User Update by: [EMAIL PROTECTED] Old-Status: Open Status: Duplicate Bug Type: Reproduceable crash Description: PHP core dumps after array_init I believe the root cause of this is a dupe of 2220. I used a DL module with debugging turned on. Previous Comments: --- [2001-04-22 23:46:33] [EMAIL PROTECTED] I've found that any PHP function can cause a core dump (Seg Fault) if it performs an array_init (return_value) function, and then subsequently returns with RETURN_FALSE or RETURN_TRUE without adding any values to the array. Perhaps occurs under other conditions also. This can easily occur in code if after the array_init call the program encounters a to which it wants to return ERROR for. Have I violated any Zend don't-do's by this? --- Full Bug description available at: http://bugs.php.net/?id=10448 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #9878 Updated: gmmktime is 1 hour off during standard time
ID: 9878 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Open Bug Type: Date/time related Operating system: Solaris 2.6 PHP Version: 4.0.4pl1 Description: gmmktime is 1 hour off during standard time Sorry, I replied to the email, but it didn't get logged to the record. Yes I'm sure Solaris2.6 does not have the tm_gmtoff value in tm struct. Linux does, perhaps newer Solaris do also, I don't know. But definately 2.6 does not have the value so the config does not set the HAVE_TM_GMTOF defined. I supposed to test on Linux you could rebuild php and override this define. If its any help, we are using the patch I suggested on a production Solaris server and it worked fine on both sides of the time shift in April. Previous Comments: --- [2001-05-07 12:52:14] [EMAIL PROTECTED] Waiting for feedback on Rasmus' question. --- [2001-05-05 15:40:26] [EMAIL PROTECTED] Are you sure that bit of code applies in your case? ie. is HAVE_TM_GMTOFF undefined in your main/php_config.h file? I am unable to recreate this problem here, but on my Linux box my gmadjust value comes straight from the libc system call ie. I have HAVE_TM_GMTOFF defined. --- [2001-03-30 10:13:58] [EMAIL PROTECTED] I know there are a lot of open bugs and this one is probably pretty small compared to most, but the time window to easily verify this bug and my suggested fix is quickly going away for 6 months. With the time shift this weekend, it wil be much more difficult to reproduce this bug, unless you start subtracting 86400 seconds per day to get back into standard time. If someone could just look at what I've provided I think it will be a no-brainer. Even if it doesn't get tagged into the new release, at least it will saved for the next. Thanks --- [2001-03-20 14:08:09] [EMAIL PROTECTED] gmmktime is producing a timestamp 1 hour off when the timezone is standard time. If you compare a time() with gmmktime with current settings and a is_dst value NULL, the results will be one hour off. I used the following little script to prove this: ? print (PRE); print (Time function = .time ()); print (n); print (gmmktime = .gmmktime (18,25,0,3,20,2001)); print (n); print (mktime = .mktime(12,25,0,3,20,2001)); print (n); print (gmmktime(7,0,0,4,1,2001). .mktime(1,0,0,4,1,2001).n); print (gmmktime(8,0,0,4,1,2001). .mktime(3,0,0,4,1,2001).n); ? Currently, the US/Central timezone is -6 hours from GMT. I believe the problem is in ext/standard/datetime.c, line 186. Judging from the code, timezone seems to be a negative seconds value from GMT, probably of the standard timezone (TZ in standard). So if is_dst == 0, you don't want to add anything more. I think the like should say: gmadjust = -(is_dst ? timezone - 3600 : timezone ); And the comment about overcorrecting removed. My test script works if this line is changed. --- Full Bug description available at: http://bugs.php.net/?id=9878 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #9878 Updated: gmmktime is 1 hour off during standard time
ID: 9878 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Date/time related Operating System: Solaris 2.6 PHP Version: 4.0.4pl1 New Comment: Can we try to get this patch in 4.0.7? Its not as critical an issue during the summer, but the standard time will be here before you know it. Previous Comments: [2001-05-07 14:10:13] [EMAIL PROTECTED] Sorry, I replied to the email, but it didn't get logged to the record. Yes I'm sure Solaris2.6 does not have the tm_gmtoff value in tm struct. Linux does, perhaps newer Solaris do also, I don't know. But definately 2.6 does not have the value so the config does not set the HAVE_TM_GMTOF defined. I supposed to test on Linux you could rebuild php and override this define. If its any help, we are using the patch I suggested on a production Solaris server and it worked fine on both sides of the time shift in April. [2001-05-07 12:52:14] [EMAIL PROTECTED] Waiting for feedback on Rasmus' question. [2001-05-05 15:40:26] [EMAIL PROTECTED] Are you sure that bit of code applies in your case? ie. is HAVE_TM_GMTOFF undefined in your main/php_config.h file? I am unable to recreate this problem here, but on my Linux box my gmadjust value comes straight from the libc system call ie. I have HAVE_TM_GMTOFF defined. [2001-03-30 10:13:58] [EMAIL PROTECTED] I know there are a lot of open bugs and this one is probably pretty small compared to most, but the time window to easily verify this bug and my suggested fix is quickly going away for 6 months. With the time shift this weekend, it wil be much more difficult to reproduce this bug, unless you start subtracting 86400 seconds per day to get back into standard time. If someone could just look at what I've provided I think it will be a no-brainer. Even if it doesn't get tagged into the new release, at least it will saved for the next. Thanks [2001-03-20 14:08:09] [EMAIL PROTECTED] gmmktime is producing a timestamp 1 hour off when the timezone is standard time. If you compare a time() with gmmktime with current settings and a is_dst value NULL, the results will be one hour off. I used the following little script to prove this: ? print (PRE); print (Time function = .time ()); print (\n); print (gmmktime = .gmmktime (18,25,0,3,20,2001)); print (\n); print (mktime = .mktime(12,25,0,3,20,2001)); print (\n); print (gmmktime(7,0,0,4,1,2001). .mktime(1,0,0,4,1,2001).\n); print (gmmktime(8,0,0,4,1,2001). .mktime(3,0,0,4,1,2001).\n); ? Currently, the US/Central timezone is -6 hours from GMT. I believe the problem is in ext/standard/datetime.c, line 186. Judging from the code, timezone seems to be a negative seconds value from GMT, probably of the standard timezone (TZ in standard). So if is_dst == 0, you don't want to add anything more. I think the like should say: gmadjust = -(is_dst ? timezone - 3600 : timezone ); And the comment about overcorrecting removed. My test script works if this line is changed. Edit this bug report at http://bugs.php.net/?id=9878edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #9822 Updated: -R ld option not being pass thru libtool
ID: 9822
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Dynamic loading
Old Operating System: Solaris 2.6 Sparc
Operating System: Solaris 2.8 Sparc
Old PHP Version: 4.0.4pl1
PHP Version: 4.1.1
New Comment:
Ugrading problem from 4.0.4p1 to 4.1.1 and Solaris 2.8.
Just retested on Solaris 2.8 with 4.1.1 and the same
behavior is present. As for a newer libtool, I have 1.4
but I don't think its used unless a buildconf is run,
which I don't need to do for this install. If I'm wrong
about this, I'd be happy to run more tests to try and get
this resolved. Its a real pain.
Previous Comments:
[2002-01-14 02:34:33] [EMAIL PROTECTED]
Does this work with 4.1.1? (and perhaps later version of libtool?)
[2001-03-18 16:24:54] [EMAIL PROTECTED]
In our environment, we depend on the -R ld options because we can't run
apache as native root, only sudo or suid bits, so LD_LIBRARY_PATH
variable is ignored. I could not get the -R options to pass on to the
ld linker, sometimes they were only set to /usr/ucblib, other times
they were null (as viewed by ldd -s phplib4.so).
I think the problem is traced to the libtool script used to compile
everything. The input definately had -R in it, but
if you add set -x to the script, the -R option was removed before it
got to the /usr/ccs/bin/ld line.
I hate to do this, but I'm including the last parts of the libtool with
set -x. It shows the -R option present early, but is gets removed
later. In this file, the last time its
present before the ld command was at line 910, the ld command is at
2352 (no -R option). Well I guess after pasting the text, the 80 char
wrapping of this form will be altering the line numbers.
Here is the output file of libtool in the final stages of the build.
=
Making all in Zend
make: Warning: Too many rules defined for target Makefile
Current working directory /home/a26811/dev/php4/php-4.0.4pl1/Zend
Making all in main
Making all in ext
Making all in mysql
Making all in libmysql
Making all in pcre
Making all in pcrelib
Making all in posix
Making all in session
Making all in standard
Making all in sybase_ct
Making all in xml
Making all in expat
Making all in xmltok
Making all in xmlparse
Making all in sapi
Making all in apache
Making all in TSRM
make: Warning: Too many rules defined for target Makefile
Current working directory /home/a26811/dev/php4/php-4.0.4pl1/TSRM
Making all in regex
Making all in .
/bin/sh /home/a26811/dev/php4/php-4.0.4pl1/libtool --silent --mode=link
cc -I. -I/home/a26811/dev/php4/php-4.0.4pl1/
-I/home/a26811/dev/php4/php-4.0.4pl1/main
-I/home/a26811/dev/php4/php-4.0.4pl1 -I/apps/soc/apache/include
-I/home/a26811/dev/php4/php-4.0.4pl1/Zend
-I/home/a26811/dev/php4/php-4.0.4pl1/ext/mysql/libmysql
-I/apps/soc/sybase/OCS-12_0/include
-I/home/a26811/dev/php4/php-4.0.4pl1/ext/xml/expat/xmltok
-I/home/a26811/dev/php4/php-4.0.4pl1/ext/xml/expat/xmlparse
-I/home/a26811/dev/php4/php-4.0.4pl1/TSRM -D_POSIX_PTHREAD_SEMANTICS
-DSOLARIS2=260 -DUSE_EXPAT -DXML_BYTE_ORDER=21 -O -xtarget=ultra -o
libphp4.la -rpath /home/a26811/dev/php4/php-4.0.4pl1/libs
-avoid-version -L/usr/ucblib -L/apps/soc/sybase/OCS-12_0/lib
-R/apps/soc/sybase/OCS-12_0/lib stub.lo Zend/libZend.la
sapi/apache/libsapi.la main/libmain.la regex/libregex.la
ext/mysql/libmysql.la ext/pcre/libpcre.la ext/posix/libposix.la
ext/session/libsession.la ext/standard/libstandard.la
ext/sybase_ct/libsybase_ct.la ext/xml/libxml.la TSRM/libtsrm.la -lpam
-ldl -ltcl -lintl -lcomn -lct -lcs -lresolv -lresolv -lm -ldl -lcrypt
-lnsl -lsocket -lsocket
Xsed=sed -e s/^X//
+ test X = Xset
LTCONFIG_VERSION=1.3.5
SHELL=/bin/sh
build_libtool_libs=yes
build_old_libs=no
fast_install=needless
host_alias=sparc-sun-solaris2.6
host=sparc-sun-solaris2.6
echo=/usr/ucb/echo
AR=ar
CC=cc
LD=/usr/ccs/bin/ld
LN_S=ln -s
NM=/usr/ccs/bin/nm -p
DLLTOOL=dlltool
OBJDUMP=objdump
AS=as
objdir=.libs
reload_flag= -r
reload_cmds=$LD$reload_flag -o $output$reload_objs
wl=-Wl,
objext=o
libext=a
exeext=
pic_flag= -KPIC
compiler_c_o=yes
compiler_o_lo=no
need_locks=no
need_lib_prefix=no
need_version=no
dlopen=unknown
dlopen_self=unknown
dlopen_self_static=unknown
link_static_flag=-Bstatic
no_builtin_flag=
export_dynamic_flag_spec=
whole_archive_flag_spec=-z allextract$convenience -z defaultextract
thread_safe_flag_spec=
version_type=linux
libname_spec=lib$name
library_names_spec=${libname}${release}.so$versuffix
${libname}${release}.so$major $libname.so
soname_spec=${libname}${release}.so$major
RANLIB=ranlib
old_archive_cmds=$AR cru $oldlib$oldobjs~$RANLIB $oldlib
old_postinstall_cmds=$RANLIB $oldlib~chmod 644 $oldlib
old_postuninstall_cmds=
old_archive_from_new_cmds=
archive_cmds=$LD
[PHP-DEV] Bug #9878 Updated: gmmktime is 1 hour off during standard time
ID: 9878 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Date/time related Operating System: Solaris 2.6 PHP Version: 4.0.4pl1 New Comment: This fix did NOT get into 4.1.1 as advertised; I just checked the 4.1.1 source I downloaded. Can someone double check how it was missed and if its in the CVS for the next release? Otherwise I can reopen it. Thanks, Brian Previous Comments: [2001-11-07 09:22:20] [EMAIL PROTECTED] Fixed in CVS [2001-10-21 21:07:02] [EMAIL PROTECTED] Missing status. [2001-07-13 10:50:06] [EMAIL PROTECTED] Can we try to get this patch in 4.0.7? Its not as critical an issue during the summer, but the standard time will be here before you know it. [2001-05-07 14:10:13] [EMAIL PROTECTED] Sorry, I replied to the email, but it didn't get logged to the record. Yes I'm sure Solaris2.6 does not have the tm_gmtoff value in tm struct. Linux does, perhaps newer Solaris do also, I don't know. But definately 2.6 does not have the value so the config does not set the HAVE_TM_GMTOF defined. I supposed to test on Linux you could rebuild php and override this define. If its any help, we are using the patch I suggested on a production Solaris server and it worked fine on both sides of the time shift in April. [2001-05-07 12:52:14] [EMAIL PROTECTED] Waiting for feedback on Rasmus' question. 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/?id=9878 Edit this bug report at http://bugs.php.net/?id=9878edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
