Re: DateUtils.equals(d1, d2)
Just checking instanceof Timestamp and JVM version concerns me, because
it seems to assume that the driver is doing the right thing. I also have
no idea how this really works for different drivers, thus my queasiness.
I like your idea of calling getTime() and rounding to the second. That
should work in all cases.
However, if either d1 or d2 do have nanosecond precision, so you really
want to ignore that information? As a programmer I'd want to belive that
DateUtils.equals(timestamp1, timestamp2) ==
timestamp1.equals(timestamp2)
for non-null values. The code below can't promise that.
How about always comparing to nanosecond precision, and just assume that
util.Date and sql.Date have those bits zero? Essentially convert Dates
to Timestamp before comparing. That might actually make this thing
semantically sound. :-)
On Tue, 17 Feb 2004 10:59:24 -0500, Serge Knystautas
[EMAIL PROTECTED] said:
DateUtils.equals(Date d1, Date d2) {
if (d1 == null || d2 == null) {
return d1 == d2;
}
boolean screwyTimestamp = d1 instanceof Timestamp
|| d2 instanceof Timestamp;
if (SystemUtils.isJavaVersionAtLeast(1.4) or !screwyTimestamp) {
return d1.getTime() == d2.getTime();
} else {
long ms1 = d1.getTime();
if (d1 instanceof Timestamp) {
ms1 += ((Timestamp) d1).getNanos() / 1000;
}
if (d2 instanceof Timestamp) {
ms2 += ((Timestamp) d2).getNanos() / 1000;
}
return ms1 == ms2;
}
}
This may not work if you've got an Oracle driver that runs in JDK 1.3
and so follows that convention, but then you're running in JDK 1.4. I
don't know how that is handled.
If that's the case, we can skip the JVM detection, and instead if it's a
timestamp round getTime() to the nearest second and then add back in
nanos/1000. This way regardless of what JVM you're in or driver you're
using, you should always get the correct number of milliseconds.
--
Serge Knystautas
President
Lokitech software . strategy . design http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DateUtils.equals(d1, d2)
Todd V. Jonker wrote:
I like your idea of calling getTime() and rounding to the second. That
should work in all cases.
Not exactly that... more like this:
long ms1 = d1.getTime();
if (d1 instanceof Timestamp) {
//First we remove milliseconds
// that some Timestamp implementations include
ms1 /= 1000;
ms1 *= 1000;
//Now add milliseconds based on nano seconds that all impls have.
ms1 += ((Timestamp) d1).getNanos() / 1000;
}
--
Serge Knystautas
President
Lokitech software . strategy . design http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DateUtils.equals(d1, d2)
Serge Knystautas wrote:
Todd V. Jonker wrote:
I like your idea of calling getTime() and rounding to the second. That
should work in all cases.
Not exactly that... more like this:
long ms1 = d1.getTime();
if (d1 instanceof Timestamp) {
//First we remove milliseconds
// that some Timestamp implementations include
ms1 /= 1000;
ms1 *= 1000;
//Now add milliseconds based on nano seconds that all impls have.
ms1 += ((Timestamp) d1).getNanos() / 1000;
}
Actually, why not also add DateUtils.getMilliseconds(Date d) so people
stuck with bad drivers can effectively get reliable getTime() behavior?
--
Serge Knystautas
President
Lokitech software . strategy . design http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] DateUtils.equals(d1, d2)
Hello, could you please use the project prefix [lang] in the subject of
such emails? It makes it easier to sort through and filter this list.
Thanks,
Gary
-Original Message-
From: Serge Knystautas [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 17, 2004 12:16
To: Jakarta Commons Developers List
Subject: Re: DateUtils.equals(d1, d2)
Serge Knystautas wrote:
Todd V. Jonker wrote:
I like your idea of calling getTime() and rounding to the second. That
should work in all cases.
Not exactly that... more like this:
long ms1 = d1.getTime();
if (d1 instanceof Timestamp) {
//First we remove milliseconds
// that some Timestamp implementations include
ms1 /= 1000;
ms1 *= 1000;
//Now add milliseconds based on nano seconds that all impls have.
ms1 += ((Timestamp) d1).getNanos() / 1000;
}
Actually, why not also add DateUtils.getMilliseconds(Date d) so people
stuck with bad drivers can effectively get reliable getTime() behavior?
--
Serge Knystautas
President
Lokitech software . strategy . design http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] 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. [EMAIL PROTECTED] -- Todd V. Jonker Conscious Code Ltd The Practice of Programming www.consciouscode.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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. [EMAIL PROTECTED] -- Todd V. Jonker Conscious Code Ltd The Practice of Programming www.consciouscode.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] RE: DateUtils.equals(d1, d2)
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. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] RE: DateUtils.equals(d1, d2)
Nope, I just added the test to ObjectUtilsTest because the test method uses ObjectUtils.equals(). I also just wanted to record the test *someplace*. Since there are problems associated with the difference in behavior b/w 1.3 and 1.4, I am not sure where this will go... Gary -Original Message- From: Serge Knystautas [mailto:[EMAIL PROTECTED] Sent: Monday, February 16, 2004 21:11 To: Jakarta Commons Developers List Subject: Re: [lang] RE: DateUtils.equals(d1, d2) 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. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DateUtils.equals(d1, d2)
Todd V. Jonker wrote: 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. I understand java.sql.Timestamp is a bit screwy, but if you read the javadoc for getTime() method, it says, Returns the number of milliseconds since January 1, 1970, 00:00:00 GMT represented by this Timestamp object. So it should return milliseconds even if it is structurally holding something different underneath. Regardless, it would help my situation... I'm using a db mapping layer (hibernate) and it sets a java.util.Date object from the ResultSet. My app code then prints to user, parses the data back, and I set the Date. I want to check whether the value is changed, and I'm actually only expecting resolution to date usually, sometimes to minute. Just my two cents from painful experience... You may want to revisit the JDBC drivers that put you through this. The ones I use now all do getTime() as milliseconds, and some of them used to do just seconds as the class-level javadoc implies. Maybe this was clarified in one of the more recent JVMs, dunno. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] RE: DateUtils.equals(d1, d2)
Also note that the behavior is different b/w java 1.3 and 1.4. Please see ObjectUtilsTest.testDateEquals() and turn on the // comments for an example. gg -Original Message- From: Serge Knystautas [mailto:[EMAIL PROTECTED] Sent: Monday, February 16, 2004 21:45 To: Jakarta Commons Developers List Subject: Re: DateUtils.equals(d1, d2) Todd V. Jonker wrote: 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. I understand java.sql.Timestamp is a bit screwy, but if you read the javadoc for getTime() method, it says, Returns the number of milliseconds since January 1, 1970, 00:00:00 GMT represented by this Timestamp object. So it should return milliseconds even if it is structurally holding something different underneath. Regardless, it would help my situation... I'm using a db mapping layer (hibernate) and it sets a java.util.Date object from the ResultSet. My app code then prints to user, parses the data back, and I set the Date. I want to check whether the value is changed, and I'm actually only expecting resolution to date usually, sometimes to minute. Just my two cents from painful experience... You may want to revisit the JDBC drivers that put you through this. The ones I use now all do getTime() as milliseconds, and some of them used to do just seconds as the class-level javadoc implies. Maybe this was clarified in one of the more recent JVMs, dunno. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] RE: DateUtils.equals(d1, d2)
Gary Gregory wrote: Also note that the behavior is different b/w java 1.3 and 1.4. Please see ObjectUtilsTest.testDateEquals() and turn on the // comments for an example. Excellent, thanks... I understand what your earlier comment was now. The calculation for 1.3 isn't too bad.. a bit laborious, and you have to throw in a JDK detection in there (nicely available in SystemUtils). I'll try to get the testcase and the code written up tomorrow. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DateUtils.equals(d1, d2)
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. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
