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
