You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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.
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.
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!
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?
Activity
SQiShER commentedon Feb 11, 2014
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.toudidel commentedon Feb 11, 2014
It's strange because I have field of type
java.util.Datein fact.I workarounded it by type checking and in case of date type I compare two strings built from before and after date value.
SQiShER commentedon Feb 11, 2014
Interesting, I would have sworn that
Dateworks 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!yrodiere commentedon May 14, 2014
For the record, the implementation of
Date.equals()only returns true when given an actualjava.util.Date)as a parameter : it actually performs a test akin toother.getClass().equals(java.util.Date.class)instead ofother instanceof Date.This is an issue when working with ORMs, such as Hibernate for instance, which uses
java.sql.Dateand other subclasses ofjava.util.Datewhen 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?toudidel commentedon May 14, 2014
Yes, comparing timestamp may be also a good workaround.
yrodiere commentedon Apr 28, 2015
Hi,
It seems you fixed it, thanks! Any idea when this could be included in a release?
SQiShER commentedon Apr 28, 2015
I can put a new release on my to-do list for this week. 😃
yrodiere commentedon Apr 29, 2015
That would be greatly appreciated :)
SQiShER commentedon May 2, 2015
@fenrhil Release 0.92 is out! Enjoy :)
yrodiere commentedon May 4, 2015
Great :) Thank you.