php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #66610 +1 Month on Leap Year
Submitted: 2014-01-30 08:01 UTC Modified: 2014-01-30 22:15 UTC
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: me at jacobt dot com Assigned:
Status: Not a bug Package: Date/time related
PHP Version: 5.5.9RC1 OS: Centos 6
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: me at jacobt dot com
New email:
PHP Version: OS:

 

 [2014-01-30 08:01 UTC] me at jacobt dot com 
Description:
------------
Please check out the following example...

http://codepad.viper-7.com/1Scqvd

I'm not sure who thought this was the right thing to do, but it's not.  For how MySQL handles it...

mysql> SELECT DATE_ADD('2009-01-30', INTERVAL 1 MONTH);
-> '2009-02-28'

I find that more acceptable.  Or, what I would actually prefer is March 1.  If you're going to add time, which is basically what you're doing here b/c a month isn't a set number of days, add the minimum number required to get the job done, no more than that...

Test script:
---------------
http://codepad.viper-7.com/1Scqvd

Expected result:
----------------
It should be clear in the file and description

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-01-30 09:53 UTC] rasmus@php.net
-Status: Open +Status: Not a bug
 [2014-01-30 09:53 UTC] rasmus@php.net 
There is no right way here. We follow the GNU standard on this one as does many, if not most, other UNIX utils which means when you say you want to add a month, we increment the month, then adjust to make sure this falls on a valid date. Feb.30 is not valid, but it is 2 days after Feb.28 which is March 2. If we didn't do this when adding a month to Jan.28, Jan.29 and Jan.30 would all give you the same result.

Try the same in sqlite or even from your Linux command line:

$ date --date='+1 month' +'Next month is %B?'
Next month is March?

See:

http://www.gnu.org/software/tar/manual/html_node/Relative-items-in-date-strings.html#SEC120

The solution is to be more specific about what you actually want. If you want the last day of next month, then say so. eg. "last day of next month" or "first day of next month"
 [2014-01-30 22:15 UTC] me at jacobt dot com 
Rasmus, your suggested solution to this issue is certainly fitting and acceptable - thank you for that.

As for the handling of the string "+1 Month", while I do understand the reasoning and logic behind it, I find it flawed, regardless of what GNU or any other platform is currently doing to this effect.  Granted, yes, it makes sense from a technical and mathematical perspective, logically it does not make sense.

I challenge you to ask any random "normal" person what their take is on it.  I would be very hard pressed to buy into the notion that they would come up with dates like March 2nd or March 3rd.  I understand that the alternative approach would have similar results for a set of up to 2-3 days, depending, however, that's perfectly acceptable.  It doesn't need to be unique.  As you state, there isn't necessarily a defined way to handle it, and a month isn't a constant.  However, there are wrong ways to handle it and I find this to be one of those cases and any other platform that handles it similarly.

I'd challenge you to step back and take an objective view of this, ask random people and consider a fix.

As for the suggested solution - that works perfectly and will use that right away and in the future.  It solves my problems, but still leaves flawed logic IMHO.

Thanks for all the work and cheers!
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sat Nov 01 08:00:02 2025 UTC