Commons Lang
  1. Commons Lang
  2. LANG-400

Add DateUtils methods to implement before and after time-insensitive

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.3
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      The JDK contains Date.before() and Date.after() but no time-insensitive versions exist. I am typically in the situation where TIMESTAMP columns are converted into Date instances and I need to compare dates only for business rules.

      I propose to complement DateUtils.isSameDay:
      DateUtils.isBeforeDay
      DateUtils.isAfterDay

      My private implementations convert Date to Calendar, zero-out the time elements, and then compare.

      PS: I would also deprecate isSameXXX methods in 2.4 and rename it to isEqualXXX since sameness usually implies instance equality, rather than object equality.

        Activity

        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Closed Closed
        556d 12h 29m 1 Henri Yandell 19/Jul/09 20:10
        Henri Yandell made changes -
        Fix Version/s Commons Time? [ 12314080 ]
        Mark Thomas made changes -
        Workflow jira [ 12420593 ] Default workflow, editable Closed status [ 12602596 ]
        Henri Yandell made changes -
        Status Open [ 1 ] Closed [ 6 ]
        Fix Version/s Commons Time? [ 12314080 ]
        Fix Version/s 3.0 [ 12311714 ]
        Resolution Won't Fix [ 2 ]
        Hide
        Henri Yandell added a comment -

        Closing and pointing to JODA Time. Setting fix version to "Commons Time?".

        Show
        Henri Yandell added a comment - Closing and pointing to JODA Time. Setting fix version to "Commons Time?".
        Henri Yandell made changes -
        Fix Version/s 3.0 [ 12311714 ]
        Fix Version/s 2.4 [ 12312481 ]
        Hide
        Henri Yandell added a comment -

        Kicking up to 3.0 until a patch shows.

        Show
        Henri Yandell added a comment - Kicking up to 3.0 until a patch shows.
        Hide
        pbenedict added a comment -

        I will provide a patch.

        Show
        pbenedict added a comment - I will provide a patch.
        Hide
        pbenedict added a comment -

        Unfortunately Java has no way to just deal with dates without dealing with time too. It's just their philosophy that dates exist on a time continuum. Anyway, truncateTime() would do fine, but I don't think that eliminates the need for isBeforeDay/isAfterDay(). Those methods I still need in many projects and they complement the already existing isSameDay().

        Show
        pbenedict added a comment - Unfortunately Java has no way to just deal with dates without dealing with time too. It's just their philosophy that dates exist on a time continuum. Anyway, truncateTime() would do fine, but I don't think that eliminates the need for isBeforeDay/isAfterDay(). Those methods I still need in many projects and they complement the already existing isSameDay().
        Hide
        Henri Yandell added a comment -

        Yep - we should only add features if they enhance the existing functionality and don't butt into any of the design 'quirks' of Java time.

        I wonder if the best way is to add an overload called truncateTime(Date) that handles your zero-out section. Seems like that would fit comfortably with the existing API, and yet still take care of the majority of your effort.

        As to renaming isSameXXX to isEqualXXX - I think we should stay as is because the English usage of 'Same' is more applicable to the time context. The spoken language isn't used to considering time as a numerical object as Java is, and so there is some benefit to the current name. Given that - we shouldn't mess with the API naming.

        Show
        Henri Yandell added a comment - Yep - we should only add features if they enhance the existing functionality and don't butt into any of the design 'quirks' of Java time. I wonder if the best way is to add an overload called truncateTime(Date) that handles your zero-out section. Seems like that would fit comfortably with the existing API, and yet still take care of the majority of your effort. As to renaming isSameXXX to isEqualXXX - I think we should stay as is because the English usage of 'Same' is more applicable to the time context. The spoken language isn't used to considering time as a numerical object as Java is, and so there is some benefit to the current name. Given that - we shouldn't mess with the API naming.
        Hide
        pbenedict added a comment -

        But Joda Time is a very sophisticated library that deals with new types of objects. I am not asking for new date-time abstractions, just supporting functions to deal with standard JDK solutions.

        Show
        pbenedict added a comment - But Joda Time is a very sophisticated library that deals with new types of objects. I am not asking for new date-time abstractions, just supporting functions to deal with standard JDK solutions.
        Hide
        ggregory@seagullsw.com added a comment -

        IMO, this is not realistic, [lang] should not end up will all of the features everyone needs in order for people to just one library (or a small set of libraries) It would be a shame and wasted effort if lang duplicates features from other open source libraries. The Date topic can grow into size and complexity rapidly. Personally, I would rather not have date features start to leak in and continue to grow over releases until we end up with the functional duplication of Joda-Time in lang.

        Show
        ggregory@seagullsw.com added a comment - IMO, this is not realistic, [lang] should not end up will all of the features everyone needs in order for people to just one library (or a small set of libraries) It would be a shame and wasted effort if lang duplicates features from other open source libraries. The Date topic can grow into size and complexity rapidly. Personally, I would rather not have date features start to leak in and continue to grow over releases until we end up with the functional duplication of Joda-Time in lang.
        Hide
        pbenedict added a comment -

        I have no idea. I would rather stick to less libraries and use Commons Lang.

        Show
        pbenedict added a comment - I have no idea. I would rather stick to less libraries and use Commons Lang.
        Hide
        ggregory@seagullsw.com added a comment -

        I always ask this when [lang] and date features are mentioned: Would Joda-Time fit your needs now?

        Show
        ggregory@seagullsw.com added a comment - I always ask this when [lang] and date features are mentioned: Would Joda-Time fit your needs now?
        pbenedict made changes -
        Field Original Value New Value
        Description The JDK contains Date.before() and Date.after() but no time-insensitive versions exist. I am typically in the situation where TIMESTAMP columns are converted into Date instances and I need to compare dates only for business rules.

        I propose to complete DateUtils.isSameDay:
        DateUtils.isBeforeDay
        DateUtils.isAfterDay

        My private implementations convert Date to Calendar, zero-out the time elements, and then compare.

        PS: I would also deprecate isSameXXX methods in 2.4 and rename it to isEqualXXX since sameness usually implies instance equality, rather than object equality.
        The JDK contains Date.before() and Date.after() but no time-insensitive versions exist. I am typically in the situation where TIMESTAMP columns are converted into Date instances and I need to compare dates only for business rules.

        I propose to complement DateUtils.isSameDay:
        DateUtils.isBeforeDay
        DateUtils.isAfterDay

        My private implementations convert Date to Calendar, zero-out the time elements, and then compare.

        PS: I would also deprecate isSameXXX methods in 2.4 and rename it to isEqualXXX since sameness usually implies instance equality, rather than object equality.
        Paul Benedict created issue -

          People

          • Assignee:
            Unassigned
            Reporter:
            Paul Benedict
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development