Skip to content

Comparing dates #85

Closed
Closed

Description

@toudidel

Comparing two dates differ always reports change only because one of them has different format.

For instance saving object with date field "2014-02-01 00:00:00.0" receives me message that it has been changed to "Sat Feb 01 00:00:00 CET 2014" (so the same value but other format).

Is it possible to ignore the format comparing dates?

Activity

  1. SQiShER commented on Feb 11, 2014

    @SQiShER
    Owner

    Do you store these dates as strings? Would it be possible to change the type to java.util.Date? That way the differ could simply use the equals method to compare the two dates. Currently I'm working on a new version that might lay the groundwork to provide custom equals methods without the need to modify the classes of the compared objects. But there is still a lot of work to do, before this version is ready to be released.

  2. toudidel commented on Feb 11, 2014

    @toudidel
    Author

    It's strange because I have field of type java.util.Date in fact.
    I workarounded it by type checking and in case of date type I compare two strings built from before and after date value.

  3. SQiShER commented on Feb 11, 2014

    @SQiShER
    Owner

    Interesting, I would have sworn that Date works fine, but now that you say it I'm not sure anymore. I'll make sure to double-check before the next release. Good to hear that you found a workaround!

  4. added this to the 0.90 milestone on Feb 11, 2014
  5. yrodiere commented on May 14, 2014

    @yrodiere

    For the record, the implementation of Date.equals() only returns true when given an actual java.util.Date) as a parameter : it actually performs a test akin to other.getClass().equals(java.util.Date.class) instead of other instanceof Date.
    This is an issue when working with ORMs, such as Hibernate for instance, which uses java.sql.Date and other subclasses of java.util.Date when retrieving entities from a database. In our team, we worked around this by comparing the timestamp (Date#getTime()) instead of the date itselft; maybe that's what you need, too?

  6. toudidel commented on May 14, 2014

    @toudidel
    Author

    Yes, comparing timestamp may be also a good workaround.

  7. modified the milestones: 0.90, on Aug 25, 2014
  8. yrodiere commented on Apr 28, 2015

    @yrodiere

    Hi,

    It seems you fixed it, thanks! Any idea when this could be included in a release?

  9. SQiShER commented on Apr 28, 2015

    @SQiShER
    Owner

    I can put a new release on my to-do list for this week. 😃

  10. yrodiere commented on Apr 29, 2015

    @yrodiere

    That would be greatly appreciated :)

  11. modified the milestones: 0.92, Backlog on May 2, 2015
  12. SQiShER commented on May 2, 2015

    @SQiShER
    Owner

    @fenrhil Release 0.92 is out! Enjoy :)

  13. yrodiere commented on May 4, 2015

    @yrodiere

    Great :) Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions