Bug #14391 Updated: gmmktime, gmdate work incorrect
ID: 14391
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Date/time related
Operating System: Windows 2000 Server
PHP Version: 4.0.6
New Comment:
Hi,
This is my first post to PHP-DEV.
I was stuck too when I tried to get timezone by subtracting
the return value of mktime() from that of gmmktime().
I've inspected the codes, and I guess this may be a complicated
and weird bug produced by glibc, MS CRT library,
ext/standard/datetime.c.
/* -- */
#include stdio.h
#include time.h
int main( int argc, char **argv )
{
struct tm tm_d = { 0, 0, 0, 1, 0, 70, 0, 0, -1 };
int seconds;
int gmadjust;
int is_dst;
is_dst = tm_d.tm_isdst;
seconds = mktime( tm_d );
gmadjust = -(is_dst ? timezone - 3600: timezone );
printf( %d\n, seconds );
seconds += gmadjust;
printf( %d %d\n, tm_d.tm_isdst, seconds );
}
/* -- */
I wrote this trivial program, and compiled and run
in two different ways.
[win32 - mingw(gcc 2.95.3) with msvcrt.dll under w2k]
c:\blah gcc -o tztest.exe tztest.c
c:\blah set TZ=JST-9:00
c:\blah tztest.exe
-1
-1 35999
c:\blah set TZ=PST+8:00
c:\blah tztest.exe
28800
0 0
[linux - gcc 3.04 and glibc-2.2.4]
$ gcc -o tztest tztest.c
$ env TZ=JST -9:00 ./tzdiff
-32400
0 0
$ env TZ=PST +8:00 ./tzdiff
28800
0 0
[What those results mean]
(a) mktime() must return -1 if the specified broken-down time cannot
be
represented as calendar time according to its spec.
(b) When the given timezone is more eastward than GMT,
libc's mktime() should fail (and return -1)
when tm.tm_hour ( -timezone / 3600 ) because of (a)
(c) glibc doesn't seem to comform to (b).
(d) MS's libc(msvcrt) does (b).
(e) If mktime() is called with tm.tm_isdst set to less than zero,
mktime() routine determines if DST is to be applied in the
specified
timezone, and should set tm_isdst to 1 (applied) or 0 (not
applied).
(f) glibc does (e) well.
(g) MS's libc(msvcrt) doesn't do (e) in case of (a) and leaves
tm.tm_isdst be.
(h) php_mktime() in ext/standard/datetime.c doesn't care about case
(b).
---
Sorry if this is not the point.
Moriyoshi Koizumi
Previous Comments:
[2002-04-08 09:40:00] [EMAIL PROTECTED]
[seen on: w2k, different php versions since 4.0.4, apache]
Please fix this! The bug still IS an important issue. For different
reasons, the main one being the 'linearity' of gmt-epoch timestamps
that is NOT given an this point. I'm in TZ+1, we just flipped DST on
and my gmt-stamps went crazy!!
$epoch = gmmktime(0,0,0,4,20,2002);
returns not (!!) the same with and without DST (e.g. use: 20.3.2002
versus 20.4.2002 as execution time)
Have some more testcases:
$timgmt = gmmktime(1,0,0,1,1,1970); //fails in TZ+1 w/o DST
$timgmt = gmmktime(0,0,0,1,1,1970); //=7199!? should be 0? (8.4.2002)
$timgmt = gmmktime(1,0,1,1,1,1970); //=0, should be 3600 (8.4.2002)
Try 'looping' across DST boundaries in two ways and you will spot the
problem instantly:
1. count up 'hours' in gmmktime()
-
print Count (+1) days from 28.3.2002:br\n;
for($day=0; $day7; $day++){
$timgmt = gmmktime(0,0,0,3,28+$day,2002);
$timloc = mktime(0,0,0,3,28+$day,2002);
print $timgmt . = gmmktim epoch - . gmdate(D d.m.Y H:i I,$timgmt)
. br\n;
print $timloc . = mktim epoch - . date(D d.m.Y H:i I,$timloc) .
brbr\n;
}
-
count days:
101727= gmmktim epoch - Wed 27.03.2002 23:00 0
101727= mktim epoch - Thu 28.03.2002 00:00 0
1017356400= gmmktim epoch - Thu 28.03.2002 23:00 0
1017356400= mktim epoch - Fri 29.03.2002 00:00 0
1017442800= gmmktim epoch - Fri 29.03.2002 23:00 0
1017442800= mktim epoch - Sat 30.03.2002 00:00 0
1017529200= gmmktim epoch - Sat 30.03.2002 23:00 0
1017529200= mktim epoch - Sun 31.03.2002 00:00 0
1017619200= gmmktim epoch - Mon 01.04.2002 00:00 0
1017612000= mktim epoch - Mon 01.04.2002 00:00 1
1017705600= gmmktim epoch - Tue 02.04.2002 00:00 0
1017698400= mktim epoch - Tue 02.04.2002 00:00 1
1017792000= gmmktim epoch - Wed 03.04.2002 00:00 0
1017784800= mktim epoch - Wed 03.04.2002 00:00 1
---
2. count up 'seconds' in gmmktime()
-
print Count (+84600) seconds from 28.3.2002:br\n;
$baseepoch = $timloc = gmmktime(0,0,0,3,28,2002);
for($day=0; $day7; $day++){
$epochnow = $baseepoch + (60 * 60 * 24 * $day);
print $epochnow . = gmmktim epoch - . gmdate(D d.m.Y H:i
I,$epochnow) . br\n;
print $epochnow . = mktim epoch - . date(D d.m.Y H:i
I,$epochnow) . brbr\n;
}
-
101727=
Bug #14391 Updated: gmmktime, gmdate work incorrect
ID: 14391
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Date/time related
Operating System: Windows 2000 Server
PHP Version: 4.0.6
New Comment:
[seen on: w2k, different php versions since 4.0.4, apache]
Please fix this! The bug still IS an important issue. For different
reasons, the main one being the 'linearity' of gmt-epoch timestamps
that is NOT given an this point. I'm in TZ+1, we just flipped DST on
and my gmt-stamps went crazy!!
$epoch = gmmktime(0,0,0,4,20,2002);
returns not (!!) the same with and without DST (e.g. use: 20.3.2002
versus 20.4.2002 as execution time)
Have some more testcases:
$timgmt = gmmktime(1,0,0,1,1,1970); //fails in TZ+1 w/o DST
$timgmt = gmmktime(0,0,0,1,1,1970); //=7199!? should be 0? (8.4.2002)
$timgmt = gmmktime(1,0,1,1,1,1970); //=0, should be 3600 (8.4.2002)
Try 'looping' across DST boundaries in two ways and you will spot the
problem instantly:
1. count up 'hours' in gmmktime()
-
print Count (+1) days from 28.3.2002:br\n;
for($day=0; $day7; $day++){
$timgmt = gmmktime(0,0,0,3,28+$day,2002);
$timloc = mktime(0,0,0,3,28+$day,2002);
print $timgmt . = gmmktim epoch - . gmdate(D d.m.Y H:i I,$timgmt)
. br\n;
print $timloc . = mktim epoch - . date(D d.m.Y H:i I,$timloc) .
brbr\n;
}
-
count days:
101727= gmmktim epoch - Wed 27.03.2002 23:00 0
101727= mktim epoch - Thu 28.03.2002 00:00 0
1017356400= gmmktim epoch - Thu 28.03.2002 23:00 0
1017356400= mktim epoch - Fri 29.03.2002 00:00 0
1017442800= gmmktim epoch - Fri 29.03.2002 23:00 0
1017442800= mktim epoch - Sat 30.03.2002 00:00 0
1017529200= gmmktim epoch - Sat 30.03.2002 23:00 0
1017529200= mktim epoch - Sun 31.03.2002 00:00 0
1017619200= gmmktim epoch - Mon 01.04.2002 00:00 0
1017612000= mktim epoch - Mon 01.04.2002 00:00 1
1017705600= gmmktim epoch - Tue 02.04.2002 00:00 0
1017698400= mktim epoch - Tue 02.04.2002 00:00 1
1017792000= gmmktim epoch - Wed 03.04.2002 00:00 0
1017784800= mktim epoch - Wed 03.04.2002 00:00 1
---
2. count up 'seconds' in gmmktime()
-
print Count (+84600) seconds from 28.3.2002:br\n;
$baseepoch = $timloc = gmmktime(0,0,0,3,28,2002);
for($day=0; $day7; $day++){
$epochnow = $baseepoch + (60 * 60 * 24 * $day);
print $epochnow . = gmmktim epoch - . gmdate(D d.m.Y H:i
I,$epochnow) . br\n;
print $epochnow . = mktim epoch - . date(D d.m.Y H:i
I,$epochnow) . brbr\n;
}
-
101727= gmmktim epoch - Wed 27.03.2002 23:00 0
101727= mktim epoch - Thu 28.03.2002 00:00 0
1017356400= gmmktim epoch - Thu 28.03.2002 23:00 0
1017356400= mktim epoch - Fri 29.03.2002 00:00 0
1017442800= gmmktim epoch - Fri 29.03.2002 23:00 0
1017442800= mktim epoch - Sat 30.03.2002 00:00 0
1017529200= gmmktim epoch - Sat 30.03.2002 23:00 0
1017529200= mktim epoch - Sun 31.03.2002 00:00 0
1017615600= gmmktim epoch - Sun 31.03.2002 23:00 0
1017615600= mktim epoch - Mon 01.04.2002 01:00 1
1017702000= gmmktim epoch - Mon 01.04.2002 23:00 0
1017702000= mktim epoch - Tue 02.04.2002 01:00 1
1017788400= gmmktim epoch - Tue 02.04.2002 23:00 0
1017788400= mktim epoch - Wed 03.04.2002 01:00 1
---
the second loop works correctly from epoch through gmdate, but gmmktime
fails to an 1 hour offset in the first place...
To sum it up: There is no way to get a correct GMT-stamp at this point,
that would remain correct through DST changes.
Previous Comments:
[2002-03-17 14:33:08] [EMAIL PROTECTED]
Reopening.
[2002-03-17 14:24:39] [EMAIL PROTECTED]
Have just replicated it with 4.1.2 on Win2K.
So Solaris and Win2K - the two biggest server platforms - are still
both affected. Could someone please sort this out? Or at least please
change the status of this bug, since there is now ample feedback that
shows that it's still alive...
[2002-02-22 05:52:09] [EMAIL PROTECTED]
I setuped php4.1.1 on my Win2K, and now there is no problem with Z
parameter in gmdate() function, but timestamp returned by gmmktime in
winter time is still wrong.
Will be this bug fixed?
[2002-02-22 05:16:06] [EMAIL PROTECTED]
Hi,
This bug is still here, and still causing grief. Sadly, it's been
marked No Feedback now. Will someone please sort this? I can't
imagine it's a particularly complicated thing to fix, since it seems to
be okay on some platforms.
Max
[2002-02-19 15:40:37] [EMAIL PROTECTED]
Any updates on this bug as it appears to still be in 4.1.1
Bug #14391 Updated: gmmktime, gmdate work incorrect
ID: 14391 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: Date/time related Operating System: Windows 2000 Server PHP Version: 4.0.6 New Comment: Have just replicated it with 4.1.2 on Win2K. So Solaris and Win2K - the two biggest server platforms - are still both affected. Could someone please sort this out? Or at least please change the status of this bug, since there is now ample feedback that shows that it's still alive... Previous Comments: [2002-02-22 05:52:09] [EMAIL PROTECTED] I setuped php4.1.1 on my Win2K, and now there is no problem with Z parameter in gmdate() function, but timestamp returned by gmmktime in winter time is still wrong. Will be this bug fixed? [2002-02-22 05:16:06] [EMAIL PROTECTED] Hi, This bug is still here, and still causing grief. Sadly, it's been marked No Feedback now. Will someone please sort this? I can't imagine it's a particularly complicated thing to fix, since it seems to be okay on some platforms. Max [2002-02-19 15:40:37] [EMAIL PROTECTED] Any updates on this bug as it appears to still be in 4.1.1 [2002-02-14 00:00:03] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2002-01-27 18:40:15] [EMAIL PROTECTED] i have two systems a)redhat 7.0 and b) win2000. both have PHP Version 4.1.1 each has exactly the same code. any calls to gmmktime on linux are fine, but win2000 is not, which is unfortunate due to the fact that it's a calendar application. any idea when this will be cleared up? 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/14391 -- Edit this bug report at http://bugs.php.net/?id=14391edit=1
Bug #14391 Updated: gmmktime, gmdate work incorrect
ID: 14391 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Open Bug Type: Date/time related Operating System: Windows 2000 Server PHP Version: 4.0.6 New Comment: Reopening. Previous Comments: [2002-03-17 14:24:39] [EMAIL PROTECTED] Have just replicated it with 4.1.2 on Win2K. So Solaris and Win2K - the two biggest server platforms - are still both affected. Could someone please sort this out? Or at least please change the status of this bug, since there is now ample feedback that shows that it's still alive... [2002-02-22 05:52:09] [EMAIL PROTECTED] I setuped php4.1.1 on my Win2K, and now there is no problem with Z parameter in gmdate() function, but timestamp returned by gmmktime in winter time is still wrong. Will be this bug fixed? [2002-02-22 05:16:06] [EMAIL PROTECTED] Hi, This bug is still here, and still causing grief. Sadly, it's been marked No Feedback now. Will someone please sort this? I can't imagine it's a particularly complicated thing to fix, since it seems to be okay on some platforms. Max [2002-02-19 15:40:37] [EMAIL PROTECTED] Any updates on this bug as it appears to still be in 4.1.1 [2002-02-14 00:00:03] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. 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/14391 -- Edit this bug report at http://bugs.php.net/?id=14391edit=1
Bug #14391 Updated: gmmktime, gmdate work incorrect
ID: 14391 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: Date/time related Operating System: Windows 2000 Server PHP Version: 4.0.6 New Comment: Hi, This bug is still here, and still causing grief. Sadly, it's been marked No Feedback now. Will someone please sort this? I can't imagine it's a particularly complicated thing to fix, since it seems to be okay on some platforms. Max Previous Comments: [2002-02-19 15:40:37] [EMAIL PROTECTED] Any updates on this bug as it appears to still be in 4.1.1 [2002-02-14 00:00:03] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2002-01-27 18:40:15] [EMAIL PROTECTED] i have two systems a)redhat 7.0 and b) win2000. both have PHP Version 4.1.1 each has exactly the same code. any calls to gmmktime on linux are fine, but win2000 is not, which is unfortunate due to the fact that it's a calendar application. any idea when this will be cleared up? [2002-01-20 10:54:51] [EMAIL PROTECTED] Here's an example: first of all, to show that the system understands what's going on: $ date +%c %Z Tue Dec 18 22:51:16 2001 GMT $ date -u +%c %Z Tue Dec 18 22:51:21 2001 GMT - same result. so the machine knows what tz it's in. Now, I'm in GMT at the moment, so echo date(H:i,mktime(22,20,00,12,18,01)).p; //gives 22.20 echo gmdate(H:i,mktime(22,20,00,12,18,01)).p; // gives 22.20 as expected. but... echo date(H:i,gmmktime(22,20,00,12,18,01)).p; //gives 21.20 echo gmdate(H:i,gmmktime(22,20,00,12,18,01)).p; // gives 21.20 These should also give 22.20, so it looks to me that gmmktime() is screwed. Max [2002-01-20 10:41:42] [EMAIL PROTECTED] I've got this problem on 4.0.5 on solaris, could someone confirm this for me? SunOS mimosa 5.7 Generic_106541-14 sun4u sparc SUNW,Ultra-4 Max 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/14391 -- Edit this bug report at http://bugs.php.net/?id=14391edit=1
Bug #14391 Updated: gmmktime, gmdate work incorrect
ID: 14391 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: Date/time related Operating System: Windows 2000 Server PHP Version: 4.0.6 New Comment: I setuped php4.1.1 on my Win2K, and now there is no problem with Z parameter in gmdate() function, but timestamp returned by gmmktime in winter time is still wrong. Will be this bug fixed? Previous Comments: [2002-02-22 05:16:06] [EMAIL PROTECTED] Hi, This bug is still here, and still causing grief. Sadly, it's been marked No Feedback now. Will someone please sort this? I can't imagine it's a particularly complicated thing to fix, since it seems to be okay on some platforms. Max [2002-02-19 15:40:37] [EMAIL PROTECTED] Any updates on this bug as it appears to still be in 4.1.1 [2002-02-14 00:00:03] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2002-01-27 18:40:15] [EMAIL PROTECTED] i have two systems a)redhat 7.0 and b) win2000. both have PHP Version 4.1.1 each has exactly the same code. any calls to gmmktime on linux are fine, but win2000 is not, which is unfortunate due to the fact that it's a calendar application. any idea when this will be cleared up? [2002-01-20 10:54:51] [EMAIL PROTECTED] Here's an example: first of all, to show that the system understands what's going on: $ date +%c %Z Tue Dec 18 22:51:16 2001 GMT $ date -u +%c %Z Tue Dec 18 22:51:21 2001 GMT - same result. so the machine knows what tz it's in. Now, I'm in GMT at the moment, so echo date(H:i,mktime(22,20,00,12,18,01)).p; //gives 22.20 echo gmdate(H:i,mktime(22,20,00,12,18,01)).p; // gives 22.20 as expected. but... echo date(H:i,gmmktime(22,20,00,12,18,01)).p; //gives 21.20 echo gmdate(H:i,gmmktime(22,20,00,12,18,01)).p; // gives 21.20 These should also give 22.20, so it looks to me that gmmktime() is screwed. Max 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/14391 -- Edit this bug report at http://bugs.php.net/?id=14391edit=1
