I think that for some reason on your system, 03 is interpreted as 0003 and not 2003 as you intended (works fine on linux). Could you try changing the year to 2003 and see if that fixes the problem?

Sorry if I misunderstand, but as my first post shows I have tried the year as 2003, as well as 03. No difference, and using the 29th as the day instead works.

Did you try:

$the_day=mktime(0,0,0,3,30,2003);

??

Yes, I have also tried (and just tried it again to make sure):

$the_day=mktime(0,0,0,3,30,2003);

Same result, -3662

Anything else I can try to narrow down where the problem might be lying?

I think this must be related to daylight savings time -- 30th March 2003 is certainly the date on which DST begins in western Europe.

Can you try this, and see what you get:

echo "23:59:59 29-Mar = ", mktime(23, 59, 59, 3, 29, 2003),
     "; 00:00:01 30-Mar = ", mktime(1, 0, 1, 3, 30, 2003);

If those timestamps are 2 seconds apart, then your original mktime() is falling into the limbo of the "lost hour" due to the clocks going back (the second after 29-Mar-2003 23:59:59 must be regarded as 30-Mar-2003 01:00:00), and the algorithm used on your system returns a nonsense value when that happens.

Mike

Of course, I meant "; 01:00:01 30-Mar = " in the second line (although the mktime() call is correct)!

ok, I used the script:
<?PHP

$the_day=mktime(0,0,0,3,30,2003);
echo "$the_day<br>";
echo "23:59:59 29-Mar = ", mktime(23, 59, 59, 3, 29, 2003),    "; 01:00:01 30-Mar = ", mktime(1, 0, 1, 3, 30, 2003);

?>

and got:

-3662
23:59:59 29-Mar = 1048982399; 01:00:01 30-Mar = -61

I thought it might be a daylight savings time problem as well, hence I thought the extra parameter I normally use would solve the problem, but it didn't. i.e.
$the_day=mktime(0,0,0,3,30,2003,0);

H'mmm -- I get

23:59:59 29-Mar = 1048982399; 01:00:01 30-Mar = 1048982401

on my system, which is what I expected from your report.  There seems to be an extra minute or so of limbo on yours for some reason.  Can you try again with:

   mktime(1, 1, 3, 3, 30, 2003)

and let us know the result.  If it's about 1048982463, then it seems there's a whole minute in there for which you don't seem to be able to get a valid time.  If it's anything else, then something is really screwy.  Either way, it seems to be a real bug.

really screwy then :-)

With the script:
<?PHP

$the_day=mktime(0,0,0,3,30,2003);
echo "$the_day<br>";
echo "23:59:59 29-Mar = ", mktime(23, 59, 59, 3, 29, 2003),    "; 01:01:03 30-Mar = ", mktime(1, 1, 3, 3, 30, 2003);

?>

I get the result:
-3662
23:59:59 29-Mar = 1048982399; 01:01:03 30-Mar = -1

Maybe -- or maybe my arithmetic is off!

Could you possibly do a bit more testing and report the first time after 01:01:03 that you get a likely result (and what it is!)?

The first result I get is when mktime() is set to:
$the_day=mktime(2,0,0,3,30,2003);

and the result is:
1048989600

instead of -1

OK! That actually seems reasonable.  In Europe at least, the DST time-change is defined to take place at 01:00:00, so the hour from 01:00:00 to 01:59:59 does not exist on that date.

So it look like the bug is that the times for the hour between 00:00:00 and 00:59:59 are wrong on a date when the clock goes back for DST.

Now that we have this pinned down, I'm going to kick this to a developer who knows about the relevant bits of the PHP source to say whether this is something PHP can address, or whether it's a bug in the date/time handling of MacOS X that you'll just have to live with.

Ok, yes that sounds reasonable.

I guess in the meantime instead of getting a time at midnight I should opt for another, say 11pm? I think I saw another post somewhere that recommends doing this to combat daylight savings time problems.

And I'll wait and see whether it is something that can be addressed by PHP or whether as you say it is an OS issue.

It's MacosX specific and not PHP bug.
And you're better off when you don't use midnight for
time anyway..

Thanks for the feedback. Will continue using mktime() at a time other than midnight.

I'm having similar problems with PHP 4.3.1 on FreeBSD 5.0-p6.

So, it is unlikely to be Mac OS X -specific (but may be xBSD specific).

I also get this bug on Mac OS X. I don't know how you can say it is bogus. OK, the time 0:0:0 on 30 Mar 03 doesn't exist. So why does it make sense to return -3662? If the input is invalid, mktime should return 0 or NULL surely? Anyway this weird behaviour should be documented.

I can not reproduce this on MacOSX, it works fine for me (with both 4.3.0 and 5.0.0-dev):

bash-2.05a$ sapi/cli/php ~/22163.php 
1049000400<br>23:59:59 29-Mar = 1049000399;
01:01:03 30-Mar = 1049004063bash-2.05a

$ uname -a
Darwin iMac.local. 6.6 Darwin Kernel Version 6.6: Thu May  1 21:48:54 PDT 2003; root:xnu/xnu-344.34.obj~1/RELEASE_PPC  Power Macintosh powerpc