|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #26111 mktime returns wrong date
Submitted: 2003-11-04 08:00 UTC Modified: 2003-11-17 18:18 UTC
Avg. Score:3.7 ± 1.5
Reproduced:11 of 12 (91.7%)
Same Version:4 (36.4%)
Same OS:7 (63.6%)
From: chris at astra dot net dot uk Assigned:
Status: No Feedback Package: Date/time related
PHP Version: 4.3.3 OS: FreeBSD
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: chris at astra dot net dot uk
New email:
PHP Version: OS:


 [2003-11-04 08:00 UTC] chris at astra dot net dot uk
mktime returns -3662 when given mktime(0,0,0,3,28,2004), i have tested this on 4.3.4RC1 with the same result.

Reproduce code:
echo date("r", mktime(0,0,0,3,28,2004))."<br>\n";

Expected result:
Sat, 28 Mar 2004 00:00:00 +0000

Actual result:
Wed, 31 Dec 1969 23:58:58 +0100


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2003-11-04 08:06 UTC]
What do these output:

echo date("r", mktime(1,1,1,3,28,2004));
echo date("r", gmmktime(1,1,1,3,28,2004));

 [2003-11-04 08:10 UTC] chris at astra dot net dot uk
echo date("r", mktime(1,1,1,3,28,2004));
echo date("r", gmmktime(1,1,1,3,28,2004));
Thu, 1 Jan 1970 00:59:59 +0100
Thu, 1 Jan 1970 00:59:59 +0100
 [2003-11-04 08:14 UTC]
Try this too:

echo mktime(12,1,1,3,28,2004);
echo gmmktime(12,1,1,3,28,2004);

Just to note: These all work just fine with Linux. :)

 [2003-11-04 08:18 UTC]
Also works fine with Freebsd 4.9-PRERELEASE (whatever that means)

 [2003-11-04 08:20 UTC] chris at astra dot net dot uk
echo mktime(12,1,1,3,28,2004);
echo gmmktime(12,1,1,3,28,2004);
both return 1080478861 (1969Sun, 28 Mar 2004 14:01:01 +0100)
 [2003-11-04 08:28 UTC] chris at astra dot net dot uk
getting the same error on 4.7-RELEASE, 4.8-RELEASE and 5.0-RELEASE.
I will install 4.9-PRERELEASE and test it now.
 [2003-11-04 09:11 UTC] chris at astra dot net dot uk
4.9-PRERELEASE gives the same error here, php was compiled from the FreeBSD ports collection (PHP 4.3.4RC1).

I am now upgrading to 4.9-RELEASE...
 [2003-11-04 16:05 UTC]
Please try using this CVS snapshot:
For Windows:

Try using the snapshot avaliable from
 [2003-11-17 18:18 UTC]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

 [2004-01-14 10:43 UTC] phpdev at egsystems dot co dot uk
I can reproduce this problem with FreeBSD 4.8-STABLE and PHP 4.3.3.

The only date affected seems to be Sunday 28 March 2004, but as I haven't looked exhaustively for other dates, who knows?

To recap:

    mktime(1,1,1,3,28,2004) returns -1. 

    It should return 1080432061.


    echo date("r", mktime(1,1,1,3,28,2004));

    prints: "Thu, 1 Jan 1970 00:59:59 +0100"

Other results using different parameters for hour, minute and second give various odd results and match those described by Chris at Astra.

On Linux/Apache and Windows/IIS with PHP 4.3.3 the problem does not occur.

The server is under the control of a hosting provider so I can't do much low-level tweaking.

I think there could be some fun on that date for anyone using FreeBSD and PHP 4.3.3 to process dates!  Good thing it's a Sunday, but still a serious bug.

Suggest this bug is set back to "Open" status and I'll keep you posted.
 [2004-01-14 11:39 UTC] phpdev at egsystems dot co dot uk
Further to above...

This appears to be due to Daylight Saving Time which begins on March 28 (in the UK in this case). I think it's safe to assume that any DST 'clocks forward' date will be similarly affected.

It's down to the way BSD (and therefore MacOSX) handle daylight savings. Because the clock goes forward at midnight on that date, there is a 'missing hour' and this apparently accounts for the strange results.

I don't really find this acceptable as the time specified 01:01:01 *does* exist AFAIK (unlike 00:00:00) on that date). Not until you specify time parameters of 2,0,0 or later does the returned timestamp appear as expected.

Using any permitted value of the 'is_dst' parameter to mktime() makes no difference.

So, it seems this is not a PHP bug at all, but a BSD one.

This is further described in Bug #23475 which is closed as 'bogus' - not the most helpful status description in this case - unless it's an anagram of 'osbug' of course).
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Tue Nov 29 04:05:53 2022 UTC