php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #49914 DateInterval doesn't implement comparison functions
Submitted: 2009-10-18 17:20 UTC Modified: 2017-04-02 04:22 UTC
Votes:106
Avg. Score:4.5 ± 0.8
Reproduced:99 of 101 (98.0%)
Same Version:26 (26.3%)
Same OS:60 (60.6%)
From: aharvey@php.net Assigned:
Status: No Feedback Package: Date/time related
PHP Version: 5.3SVN-2009-10-18 (SVN) OS: *
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: aharvey@php.net
New email:
PHP Version: OS:

 

 [2009-10-18 17:20 UTC] aharvey@php.net
Description:
------------
(This is really a feature request, rather than a bug per se.)

Unlike DateTime objects, DateInterval objects cannot easily be compared within PHP. While it would be possible to concoct a workaround in userspace using a few calls to DateInterval::format() and some arithmetic, it would probably be preferable to implement it within ext/date itself.

I've prepared a patch (yes, it even has a simple test) against PHP_5_3 at http://www.adamharvey.name/patches/DateInterval-comparators.patch which implements comparator support. I can probably prepare a HEAD patch if necessary; I just don't have a HEAD checkout to hand to do so at present.

There's one fairly significant issue with this patch worth noting: I've implemented a new function (timelib_rel_time_to_seconds) which converts a timelib_rel_time structure to the number of seconds it represents. The issue with this is that, as per bug #49778, we don't always know exactly how many days a timelib_rel_time actually represents because of the varying number of days in a month and year.

As per the comments in the function, for now I've fudged it and effectively chosen the default length of a month and year out of thin air if the days field isn't set within the structure. If the resolution to bug #49778 results in the days field always being filled in, then timelib_rel_time_to_seconds can be simplified accordingly. Alternatively, we could only support this in cases where we definitely know the days within the timelib_rel_time structure and error out otherwise.

As a side note, I have a second patch that I can upload that implements support for a DateInterval::getSeconds() method which effectively provides a PHP wrapper around the proposed internal timelib_rel_time_to_seconds function. If it's decided to accept this approach, I can create another bug to track getting that in.

Reproduce code:
---------------
<?php
$ten = new DateInterval('PT10S');
$twenty = new DateInterval('PT20S');
var_dump($ten < $twenty);
?>

Expected result:
----------------
bool(true)

Actual result:
--------------
bool(false)

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-11-24 10:50 UTC] jani@php.net
-Package: Feature/Change Request +Package: Date/time related
 [2011-11-25 11:01 UTC] albertcasademont at gmail dot com
Did this patch make it into the trunk?
 [2012-03-23 00:35 UTC] kavi at postpro dot net
So... patch submitted 2.5 years ago.

Sup guys?
 [2012-09-26 15:25 UTC] jrbeaure at uvm dot edu
I need to be able to compare date intervals.
 [2015-12-03 14:28 UTC] will dot tinsdeall at mercianlabels dot com
Any closer to applying a fix on this? It's a real shame it didn't make it into 7.0
 [2017-03-24 06:28 UTC] heiglandreas@php.net
-Status: Open +Status: Feedback
 [2017-03-24 06:28 UTC] heiglandreas@php.net
Just one small question to those that commented here: How would you compare those two intervals: P1M and P30D - which one is the greater one? is it P1M even though I'm currently in february? Or is it P30D even though I'm currently in August? What about PT24H30M and P1D? Under certain circumstances a Day can have more or less that 24 hours (DST-transition)

Even though those might be edge-cases exactly those edge-cases need to be handled or they will show up here in the bug-tracker. 

So I'd really like to get some feedback on how you think those edge-cases should be handled. Otehrwise there are some userland libraries that handle most aspects of Interval-COmparison but not those edge-cases… (f.e but not limited to https://packagist.org/packages/org_heigl/dateintervalcomparator)
 [2017-04-02 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 [2019-01-04 16:15 UTC] photon0 at gmail dot com
@heiglandreas
I would argue that the simplest way to compare these objects (since there is no real accurate way to do so) is to compare two DateTime starting at Unix epoch and each offset by ->add(DateInterval).
I don't think this request is sugar coating.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Apr 27 12:01:29 2024 UTC