[PHP-DOC] #22198 [Ana]: date() returning incorrect date

2003-02-13 Thread jm
 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;$hour2;$hour++) {
for($min=0;$min60;$min++) {
for($seg=0;$seg60;$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=22198edit=1


-- 
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP-DOC] #22198 [Ana]: date() returning incorrect date

2003-02-12 Thread sniper
 ID:   22198
 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:

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.



Previous Comments:


[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;$hour2;$hour++) {
for($min=0;$min60;$min++) {
for($seg=0;$seg60;$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
...



[2003-02-12 21:30:23] [EMAIL PROTECTED]

Try using some other time that midnight. Some systems
tend to behave a bit differently during the dst change
and in those systems, the hour between 00:00 - 01:00 doesn't
exist..(e.g. Macosx does the same)




[2003-02-12 21:07:03] [EMAIL PROTECTED]

=
TIME END 2003-02-13 03:02:41
=
TEST RESULT SUMMARY
-
Exts skipped:   76
Exts tested :   14
-
Number of tests :  443
Tests skipped   :  221 (49.9%)
Tests failed:3 ( 0.7%)
Tests passed:  219 (49.4%)
-
Time taken  :  111 seconds
=

=
FAILED TEST SUMMARY
-
Error message handling [tests/run-test/test005.phpt]
Bug #21131: fopen($filename, a+) has broken position
[ext/standard/tests/file/bug21131.phpt]
strtotime() function [ext/standard/tests/time/002.phpt]
=



[2003-02-12 20:41:07] [EMAIL PROTECTED]

We are waiting for your feedback about the result of the test.

Thank you.



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=22198edit=1


-- 
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP-DOC] #22198 [Ana]: date() returning incorrect date

2003-02-12 Thread jm
 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:

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
...


Previous Comments:


[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;$hour2;$hour++) {
for($min=0;$min60;$min++) {
for($seg=0;$seg60;$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
...



[2003-02-12 21:30:23] [EMAIL PROTECTED]

Try using some other time that midnight. Some systems
tend to behave a bit differently during the dst change
and in those systems, the hour between 00:00 - 01:00 doesn't
exist..(e.g. Macosx does the same)




[2003-02-12 21:07:03] [EMAIL PROTECTED]

=
TIME END 2003-02-13 03:02:41
=
TEST RESULT SUMMARY
-
Exts skipped:   76
Exts tested :   14
-
Number of tests :  443
Tests skipped   :  221 (49.9%)
Tests failed:3 ( 0.7%)
Tests passed:  219 (49.4%)
-
Time taken  :  111 seconds
=

=
FAILED TEST SUMMARY
-
Error message handling [tests/run-test/test005.phpt]
Bug #21131: fopen($filename, a+) has broken position
[ext/standard/tests/file/bug21131.phpt]
strtotime() function [ext/standard/tests/time/002.phpt]
=



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=22198edit=1


-- 
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php