Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85799
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.11.1504132119580.5873@whisky.home.derickrethans.nl>
References: <CAEU6NAc-3aPHhADxPa-ELtkvsAWFm37D29VPfM+iYvcPrn1ukA@mail.gmail.com>
 <alpine.DEB.2.11.1504132119580.5873@whisky.home.derickrethans.nl>
Date: Tue, 14 Apr 2015 08:45:21 +0200
Message-ID: <CAEU6NAcBXtp4Wmsw66J-FHdP30AFGW_JYN1jtkrzNQN6csEbew@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113479205474790513a9942f
Subject: Re: [PHP-DEV] DateInterval bug
From: peter.e.lind@gmail.com (Peter Lind)

--001a113479205474790513a9942f
Content-Type: text/plain; charset=UTF-8

On 13 April 2015 at 22:20, Derick Rethans <derick@php.net> wrote:

> On Sun, 12 Apr 2015, Peter Lind wrote:
>
> > Hi,
> >
> > I wanted to get into PHP code development so I grabbed a random bug from
> > bugs.php.net. Which turned out to be
> https://bugs.php.net/bug.php?id=69378
> >
> > The problem the bug report describes is that creating a diff between two
> > dates and then subtracting the diff from the later date does not give you
> > the former date. Or, as the bug report state, this should hold:
> >
> > B - (B - A) == A
> >
> > But it doesn't, because of the way DateInterval and DateTime interact. A
> > DateInterval is broken up into years, months, days, hours, minutes and
> > seconds - which can be added or subtracted from a date. However, months
> are
> > not fit size, so the order in which things are added or subtracted
> matters.
> > In the bug report, the problem arises because months are subtracted
> before
> > days - and there's a huge difference between subtracting 17 days from 2.
> > April and from 2. March.
> >
> > In itself, this isn't a big problem - but apparently this behaviour is
> how
> > the system is supposed to work. In the tests for the date extension, I
> > found this test for DateTime::add
> >
> > echo "test_years_positive__6_shy_1_day: ";
> > examine_diff('2007-02-06', '2000-02-07', 'P+6Y11M30DT0H0M0S', 2556);
> >
> > echo "test_years_negative__6_shy_1_day: ";
> > examine_diff('2000-02-07', '2007-02-06', 'P-6Y11M28DT0H0M0S', 2556);
> >
> > The third argument in the examine_diff calls is used in the constructor
> > call to DateInterval. The difference is whether the interval will be
> > positive or negative. Note the difference of two days - if you add a
> > positive interval, then 7 years minus 1 day is 6 years, 11 months and 30
> > days. If you add a negative interval, then 7 years minus 1 day is 6
> years,
> > 11 months and 28 days.
> >
> > Is there a good explanation for this behaviour (which applies both to
> > DateTime::add and DateTime::sub)? I've tried searching the internals list
> > but couldn't see any discussion of it. It seems like a bug that never got
> > fixed to the point where there are tests to make sure things are still
> > calculated wrong.
>
> Why is it a bug? With DateTime math, reversing an operation isn't
> necessarily going to work...
>
>
Forgot to mention - this has nothing to do with reversing operations. As
you can see from the unit tests for the Date extension, figuring out what
the interval is between two dates depends on knowing which dates you're
dealing with and if your interval is positive or negative. The fact that
the bug shows up for the example in the bug report is just a symptom of the
underlying problem.

Regards
Peter


-- 
<hype>
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
</hype>

--001a113479205474790513a9942f--