Bug #49081 [Asn->Csd]: [PATCH] DateTime::diff() mistake if start in January and interval > 28 days

From: Date: Tue, 04 May 2010 15:12:10 +0000
Subject: Bug #49081 [Asn->Csd]: [PATCH] DateTime::diff() mistake if start in January and interval > 28 days
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-150172@lists.php.net to get a copy of this message
Edit report at http://bugs.php.net/bug.php?id=49081&edit=1

 ID:               49081
 Updated by:       derick@php.net
 Reported by:      nate at frickenate dot com
 Summary:          [PATCH] DateTime::diff() mistake if start in January
                   and interval > 28 days
-Status:           Assigned
+Status:           Closed
 Type:             Bug
 Package:          Date/time related
 Operating System: *
 PHP Version:      5.3.0
 Assigned To:      derick

 New Comment:

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:
------------------------------------------------------------------------
[2010-05-04 17:11:44] derick@php.net

Automatic comment from SVN on behalf of derick
Revision: http://svn.php.net/viewvc/?view=revision&revision=298973
Log: - Fixed bug #49081 (DateTime::diff() mistake if start in January
and interval >
  28 days). (Derick)

------------------------------------------------------------------------
[2010-01-23 00:10:21] danielc@php.net

Here is an updated patch against PHP_5_3.  It removes all of the
"next_month" code in 

do_range_limit_days_relative().
http://www.analysisandsolutions.com/php/bug49081v2.53.diff

As with the earlier patch, PHP built fine with it and all of the
ext/date tests that passed under 

the unpached PHP_5_3 build continued to pass under the patched version.

Grepping the entire PHP_5_3 code base indicates the only place
do_range_limit_days_relative() gets 

called is in timelib_do_rel_normalize(), and the only place that gets
called is timelib_diff().

It is unclear what purpose the "next_month" functionality served. 
Perhaps it was there in case the 

"base_y" and "base_m" parameters were later than the
"y"/"m"/"d"
parameters?  But that doesn't apply 

becausetimelib_diff() always passes the earlier date to
timelib_do_rel_normalize() as "one" and on to 

do_range_limit_days_relative() as "base_*".

------------------------------------------------------------------------
[2010-01-06 16:19:14] danielc@php.net

Hmm... Isn't the whole days_next_month functionality in
do_range_limit_days_relative() unnecessary?

------------------------------------------------------------------------
[2010-01-06 01:04:18] danielc@php.net

A better test file:
http://www.analysisandsolutions.com/php/bug49081v2.phpt

The scenarios it covers are more relevant and thorough, plus it improves
the context, making it easier see what the test is doing.

------------------------------------------------------------------------
[2010-01-05 22:11:57] danielc@php.net

This bug continues to exist in 5.3.2RC2.

DateTime::diff() / date_diff() chokes on dates starting in January if
the interval is greater than 28 days (during non-leap years).

It is happening because of a bug in do_range_limit_days_relative() in
ext/date/lib/tm2unixtime.c.  At the end of the function if *d >
days_next_month, the code subtracts the days and adds a month.  So when
the starting month is January, the days_next_month is 28 or 29,
mistakenly triggering the month/day swapping behavior.

Patch:
http://www.analysisandsolutions.com/php/bug49081.diff

Test:
http://www.analysisandsolutions.com/php/bug49081.phpt

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    http://bugs.php.net/bug.php?id=49081


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=49081&edit=1


Thread (8 messages)

« previous php.bugs (#150172) next »