You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <gg...@seagullsw.com> on 2004/02/17 00:41:44 UTC

[lang] RE: DateUtils.equals(d1, d2)

I've also added a test to ObjectUtilsTest to show this time issue.

gg

> -----Original Message-----
> From: Gary Gregory [mailto:ggregory@seagullsw.com]
> Sent: Monday, February 16, 2004 14:13
> To: 'Jakarta Commons Developers List'
> Subject: RE: DateUtils.equals(d1, d2)
> 
> See alse the bug report for an example of this not working...
> 
> gg
> 
> > -----Original Message-----
> > From: Todd V. Jonker [mailto:todd@consciouscode.com]
> > Sent: Monday, February 16, 2004 13:21
> > To: Jakarta Commons Developers List
> > Subject: Re: DateUtils.equals(d1, d2)
> >
> > Serge, I'm not sure that your proposed method will do what you want.
> >
> > You can't compare the results of java.util.Date.getTime() and
> > java.sql.Timestamp.getTime() because the latter is only precise to the
> > second, not the millisecond.  Likewise, java.sql.Date.getTime() is only
> > precise to the second.
> >
> > Unless you do rather snarly logic, it may not be meaningful to compare
> > any util.Date with any of the sql types.  Quoting from the Timestamp
> API:
> >
> > "Due to the differences between the Timestamp class and the
> > java.util.Date  class mentioned above, it is recommended that code not
> > view Timestamp values generically as an instance of java.util.Date. The
> > inheritance relationship between Timestamp  and java.util.Date really
> > denotes implementation inheritance, and not type inheritance."
> >
> > To compare a until.Date with a sql.Timestamp you'll have to rebuild the
> > latter's time to millisecond precision by call getNanos(), rounding the
> > result to the millisecond, and adding it to getTime().  And if you want
> > "true" equality you'll have to fail if the submillisecond nanos aren't
> > zero.  Doing all of that is of debatable usefulness, because the use of
> > such a somewhat-generic equality method probably indicates that the
> > programmer doesn't understand the subtleties here and he's probably
> > writing a bug.  :-)
> >
> > Just my two cents from painful experience...
> >
> > .T.
> >
> >
> >
> > On Fri, 13 Feb 2004 18:12:37 -0500, "Serge Knystautas"
> > <se...@lokitech.com> said:
> > > There was a bugzilla issue opened about this, and a brief discussion
> > > about such, but I wanted to move it to the list for better visibility.
> > >
> > > Basically if you have 2 date objects (e.g., java.util.Date and
> > > java.sql.Timestamp), ObjectUtils.equals() will return that they are
> not
> > > equal even if they represent the same point in time.
> > >
> > > Unless someone objects, I was going to add DateUtils.equals(Date d1,
> > > Date d2) and the equality check will be what's returned from each
> date's
> > > getTime().  Just as an example:
> > >
> > > long now = System.currentTimeMillis();
> > > Date date = new java.util.Date(now);
> > > Date ts = new java.sql.Timestamp(now);
> > >
> > > ObjectUtils.equals(date, ts) = false; (as of 2.1)
> > > DateUtils.equals(date, ts) = true;
> > >
> > > Anyone have a different idea or think this is a bad idea?
> > >
> > > --
> > > Serge Knystautas
> > > President
> > > Lokitech >>> software . strategy . design >> http://www.lokitech.com
> > > p. 301.656.5501
> > > e. sergek@lokitech.com
> >
> > --
> > Todd V. Jonker
> >
> > Conscious Code Ltd
> > The Practice of Programming
> > www.consciouscode.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [lang] RE: DateUtils.equals(d1, d2)

Posted by Serge Knystautas <se...@lokitech.com>.
Gary Gregory wrote:
> I've also added a test to ObjectUtilsTest to show this time issue.

Gary,

Are you suggesting ObjectUtils should handle this Date comparison?

-- 
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org