I can't reproduce this to FreeBSD/Linux/Windows XP.

It outputs:

1048892400
29/03/2003
1048978800
30/03/2003

Anyway the timestamp is right, date might be the problem. Are  you sure you're really running this script?

Please run "run-tests.php ext/standard/time/mktime.phpt" from your PHP source dir and add the output to this report.

on freebsd x86:

$ php -v
4.2.1
$ uname -sr
FreeBSD 4.6-STABLE
$ php -q data.php
1048896000
29/03/2003
1048982400
30/03/2003

on sparc:

$ php -v
PHP 4.3.0 (cli) (built: Feb 10 2003 18:07:11)
Copyright (c) 1997-2002 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies
    with Zend Optimizer v2.1.0, Copyright (c) 1998-2003, by Zend Technologies
$ uname -sr
SunOS 5.8
$ php -q data.php
1048896000
29/03/2003
1048978800
29/03/2003

Timestamps are different

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

Thank you.

=====================================================================
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]
=====================================================================

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)

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

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!)

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.

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

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

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

I have a very similar problem to this but with much more severe symptoms.

sol# php -v
PHP 4.3.0 (cli) (built: Feb  1 2003 23:36:25)
Copyright (c) 1997-2002 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies
sol# uname -sr
FreeBSD 4.7-STABLE
sol# php -q data.php
1048896000
29/03/2003
-3662
31/12/1969

Ditto on FreeBSD 4.7:

echo mktime(0, 0, 0, 3, 29, 2003) . "\n";
echo mktime(0, 0, 0, 3, 30, 2003) . "\n";
echo mktime(0, 0, 0, 3, 31, 2003) . "\n";

gives:

1048896000
-3662
1049065200

This from a machine in the UK, where we switched to DST
on the date in question.

I have the same problem running on Mac OS X

php -q -r 'print mktime(0,0,0,3,30,2003) . "\n";'
-3662

Same happens for 3/31/2003 so is clearly related to DST.

I am running windows2k, php4.3.4, apache 2.0.48 and I encounter the same issue with this code.
<?
print mktime(23,0,0,3,27,2004)."\n";
print mktime(0,0,0,3,28,2004)."\n";
?>

Outputs:
1080428400
1080428400

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.

"Some times are invalid if DST is on. If DST is enabled in e.g. 2:00, all times between 2:00 and 3:00 are invalid and mktime returns undefined (usually negative) value. Some systems (e.g. Solaris 8) enable DST in midnight so time 0:30 of the day when DST is enabled is evaluated as 23:30 of the previous day."