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.
Regards
Peter
--
<hype>
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
</hype
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.
This is where it simply is not possible to use the expanded value with
any sense of reality. All of my work with genealogical data has always
worked in 'days', and while an interval can be displayed as an
approximate number of years, even this will be wrong if the period goes
over a leap year or not. Obviously months have the same random results
over February, so adding 1 month 30 days is simply meaningless? You need
more detail to decide just what length that month is!
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
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=69378The 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::addecho "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...
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
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=69378The 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::addecho "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...
Math that isn't consistent is problematic, in my book. Or, to put it
another way: if someone told me, that there is 6 years, 11 months and 30
days between 7th Feb 2000 and 6th Feb 2007, I would agree. If the same
person then told me that the interval is also 6 years, 11 months and 28
days and that both intervals are correct - I would question the sanity of
that person. I would go so far as to say: don't ever manage my calendar.
The bug as I see it is that two classes/behaviours have been packed into
one - there should be DateIntervalRepresentation and DateInterval. The
first shows you how many years, months, days, etc there are between two
dates. The second is the actual interval between two dates. The first is
context dependent - it needs anchoring in at least one date. The second is
context independent.
Either that or do away with math you can't rely on. I think what we should
aim for in programming languages is the opposite of "isn't necessarily
going to work..."
Regards
Peter
--
<hype>
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
</hype
Hi All.
Am 14.04.15 um 08:38 schrieb Peter Lind:
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=69378The 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::addecho "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...Math that isn't consistent is problematic, in my book. Or, to put it
another way: if someone told me, that there is 6 years, 11 months and 30
days between 7th Feb 2000 and 6th Feb 2007, I would agree. If the same
person then told me that the interval is also 6 years, 11 months and 28
days and that both intervals are correct - I would question the sanity of
that person. I would go so far as to say: don't ever manage my calendar.The bug as I see it is that two classes/behaviours have been packed into
one - there should be DateIntervalRepresentation and DateInterval. The
first shows you how many years, months, days, etc there are between two
dates. The second is the actual interval between two dates. The first is
context dependent - it needs anchoring in at least one date. The second is
context independent.Either that or do away with math you can't rely on. I think what we should
aim for in programming languages is the opposite of "isn't necessarily
going to work..."Regards
Peter
As far as I can see in http://3v4l.org/mUeRk in PHP 5.3.2 the behaviour
was still as you'd expect it, in PHP5.3.3 it was as described in the
ticket. So it seems that there has been a change introduced with
PHP5.3.3 that "broke" the "expected" behaviour.
Cheers
Andreas
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca |
+---------------------------------------------------------------------+
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=69378The 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::addecho "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