php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #63878 date time function issue problem
Submitted: 2012-12-31 12:55 UTC Modified: 2013-01-01 08:21 UTC
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: rupesh dot php at gmail dot com Assigned:
Status: Not a bug Package: *General Issues
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
 [2012-12-31 12:55 UTC] rupesh dot php at gmail dot com
Description:
------------
---
From manual page: http://www.php.net/function.date#refsect1-function.date-seealso
---

The date time related functions do not work properly when the current date is 31st of a month, like today is 31st December 2012.. It seems to be working on a 30 day principle for a month and does not return the desired output whenever we you a +/- 1month ting with strtotime() function or with a mktime() function.
The issue is depicted in the script mentioned below with the output that I get.

Script ::
---------
for($i=0; $i<6; $i++)
{
    echo date("Y-M-d", mktime(0, 0, 0, date("m")-$i, date("d"),   date("Y")))."<br>";
    // or even with 
    // echo date("Y-M-d", strtotime("-".$i."day"))."<br>";
}

Outputs ::
----------
2012-Dec-31
2012-Dec-01
2012-Oct-31
2012-Oct-01
2012-Aug-31
2012-Jul-31

instead, it should have been ::
-------------
2012-Dec-31
2012-Nov-30
2012-Oct-31
2012-Sep-30
2012-Aug-31
2012-Jul-31

Note that I have only come across this issue with today being 31st of the month.

Test script:
---------------
for($i=0; $i<6; $i++)
{
    echo date("Y-M-d", mktime(0, 0, 0, date("m")-$i, date("d"),   date("Y")))."<br>";
    // or even with 
    // echo date("Y-M-d", strtotime("-".$i."day"))."<br>";
}


Expected result:
----------------
2012-Dec-31
2012-Nov-30
2012-Oct-31
2012-Sep-30
2012-Aug-31
2012-Jul-31

Actual result:
--------------
2012-Dec-31
2012-Dec-01
2012-Oct-31
2012-Oct-01
2012-Aug-31
2012-Jul-31

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-12-31 21:25 UTC] mail+php at requinix dot net
Take a close look at the documentation for mktime().

day
The number of the day relative to the end of the previous month. [...] Values 
greater than the number of days in the relevant month reference the appropriate 
day in the following month(s).

When you told it to create a time for "November 31st, 2012" it overflowed the day 
number into December. Same for September/October. Likewise if you had it go all 
the way back to February it would have given you March 2nd.
 [2013-01-01 07:15 UTC] rupesh dot php at gmail dot com
Got your point, but isn't that an irrelevant logic.
If someone is trying to do +/- month on the last day of that month, as in my case, then it should be pointed to the last day of the previous month, instead of being pointed to the 1st day or so of the current month.
 [2013-01-01 07:30 UTC] rasmus@php.net
-Status: Open +Status: Not a bug
 [2013-01-01 07:30 UTC] rasmus@php.net
No, for better or worse, this is how UNIX works with relative dates. PHP is 
consistent with the GNU utilities and the related glibc functions. The choice 
the UNIX guys had to make was whether to make these operations reversible. If 
you added a month to Oct.31 and truncated it to Nov.30 and then subtracted a 
month from Nov.30 you would end up at Oct.30 which wasn't where you started, and 
that would be a problem in many scenarios. If you type: man mktime
at your Linux prompt you will see that they give this example:

   if structure members are outside their valid interval, they will
   be normalized (so that, for example, 40 October is changed into 
   9 November)

and since PHP is just a thin layer on top of these underlying libraries this 
behaviour is inherited.

And you will also find that if you do similar relative date manipulation with 
the UNIX date command it works the same way. Many/most databases behave this way 
too.

Further reading here:

http://www.gnu.org/software/tar/manual/html_node/Relative-items-in-date-
strings.html#SEC120
 [2013-01-01 08:21 UTC] rupesh dot php at gmail dot com
Well okay.. I got your point..
So it seems like we cannot really call it a bug, instead it is kind off an avoidable exception, which we will have to live with..
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu May 02 07:01:30 2024 UTC