Bug #14391 Updated: gmmktime, gmdate work incorrect

ID: 14391 Updated by: jazimmer@mapfree.com Reported By: pilots@farlep.net Status: Open Bug Type: Date/time related Operating System: Windows 2000 Server PHP Version: 4.0.6 New Comment: Here's a different perspective: I've been duplicating examples in Python, Perl, Tcl, and PHP, thinking my next book may be full of such. One of my examples converts between an ASCII GMT representation and the local machine's seconds since the epoch. I did the example in the other languages before trying PHP. Tcl works "out of the box". In Python and Perl, I found ways of getting the gmt-to-local time differential and used that differential to adjust the result produced by mktime to create something similar to PHP's mktime. (It's not well tested but doesn't have the bug PHP's mktime has. I get correct results for daylight and nondaylight local times.) In PHP, I can't find tools sufficient to calculate that time differential. HERE's THE POINT: All these languages seem to rely on the same basic C library. If it can be done using those C library tools (however indirectly) in some of them it ought to be possible in all. J Adrian Zimmer Previous Comments: ------------------------------------------------------------------------ [2002-04-17 21:03:39] readjust@deneb.freemail.ne.jp 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 ------------------------------------------------------------------------ [2002-04-08 09:40:00] patrick@arch.ethz.ch [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; $day<7; $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) . "<br><br>\n"; } --------- count days: 1017270000= gmmktim epoch - Wed 27.03.2002 23:00 0 1017270000= 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; $day<7; $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) . "<br><br>\n"; } --------- 1017270000= gmmktim epoch - Wed 27.03.2002 23:00 0 1017270000= 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. ------------------------------------------------------------------------ [2002-03-17 14:33:08] sander@php.net Reopening. ------------------------------------------------------------------------ [2002-03-17 14:24:39] max@flipstorm.net 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] pilots@farlep.net 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? ------------------------------------------------------------------------ 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=14391&edit=1