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: <? for($hour=0;$hour<2;$hour++) { for($min=0;$min<60;$min++) { for($seg=0;$seg<60;$seg++) { $mk2= mktime ($hour,$min,$seg,03,30,2003); $frm2 = date ("d/m/Y", $mk2); print "($hour h, $min m, $seg s) $mk2 --> $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