views:

240

answers:

7

The Java class library has a class named DateTime. DateTime has this method:

int daysBetween(DateTime other)

which returns the number of days between this and the parameter. It doesn't have a method

int secondsBetween(DateTime other)

which I happen to need. Is there a class which is similar to DateTime but has such a method?

A: 

Which class ? Do you mean the Joda DateTime class ? If so, you can simply call getMillis() on each, and perform the appropriate subtraction/scaling.

I would recommend Joda for date/time work, btw, due to it's useful and intuitive API, and its thread-safety for formatting/parsing options.

Brian Agnew
http://openemed.net/javadocs/tools/ydocs/gov/lanl/Utility/DateTime.html
snakile
That's not a standard library (neither is Joda), nor is it particularly well-know (unlike Joda)
Brian Agnew
+2  A: 

There is no such class as DateTime in the standard Java SE API. Although there is one in joda-time, even that does not have a daysBetween method.

Using the standard Java API, the easiest way to get seconds between two java.util.Date objects would be to subtract their timestamps and divide by 1000:

int secondsBetween = (date1.getTime() - date2.getTime()) / 1000;
andri
Ninja'd me by a couple of seconds. +1
Drew
+3  A: 

Not familiar with DateTime...

If you have two Dates you can call getTime on them to get millseconds, get the diff and divide by 1000. For example

Date d1 = ...;
Date d2 = ...;
int seconds = (d2.getTime()-d1.getTime())/1000;

If you have Calendar objects you can call

c.getTimeInMillis()

and do the same

Scott Stanchfield
+2  A: 

That should do it:

Date a = ...;
Date b = ...;

Math.abs(a.getTime()-b.getTime())/1000;

Here the relevant documentation: Date.getTime(). Be aware that this will only work for dates after January 1, 1970, 00:00:00 GMT

Johannes Weiß
Hmm, why would this only work for dates after Jan 1, 1970? Before that the values are negative, but arithmetic works on negative numbers.
Jay
A: 

It is not recommended to use java.util.Date or System.currentTimeMillis() to measure elapsed times. These dates are not guaranteed to be monotonic and will changes occur when the system clock is modified (eg when corrected from server). In probability this will happen rarely, but why not code a better solution rather than worrying about possibly negative or very large changes?

Instead I would recommend using System.nanoTime().

long t1 = System.nanoTime();
long t2 = System.nanoTime();

long elapsedTimeInSeconds = (t2 - t1) / 1000000000;

EDIT

For more information about monoticity see the answer to a related question I asked, where possible nanoTime uses a monotonic clock. I have tested but only using Windows XP, Java 1.6 and modifying the clock whereby nanoTime was monotonic and currentTimeMillis wasn't.

Also from Java's Real time doc's:

Q: 50. Is the time returned via the real-time clock of better resolution than that returned by System.nanoTime()?

The real-time clock and System.nanoTime() are both based on the same system call and thus the same clock.

With Java RTS, all time-based APIs (for example, Timers, Periodic Threads, Deadline Monitoring, and so forth) are based on the high-resolution timer. And, together with real-time priorities, they can ensure that the appropriate code will be executed at the right time for real-time constraints. In contrast, ordinary Java SE APIs offer just a few methods capable of handling high-resolution times, with no guarantee of execution at a given time. Using System.nanoTime() between various points in the code to perform elapsed time measurements should always be accurate.

Pool
Hmm, interesting post. What makes you say that nanoTime is not subject to clock updates? I don't see anything in the Java documentation about this. I'm not saying you're wrong, I'm must wondering if you have a reference or have performed experiments to back this up.
Jay
I've updated the answer with more information.
Pool
A: 

Just a pointer: If you're calculating the difference between two java.util.Date the approach of subtracting both dates and dividing it by 1000 is reasonable, but take special care if you get your java.util.Date reference from a Calendar object. If you do so, you need to take account of daylight savings of your TimeZone since one of the dates you're using might take place on a DST period.

That is explained on Prasoon's link, I recommend taking some time to read it.

seibzhen
A: 

If you're using Joda (which may be coming as jsr 310 in JDK 7, separate open source api until then) then there is a Seconds class with a secondsBetween method.

Here's the javadoc link: http://joda-time.sourceforge.net/api-release/org/joda/time/Seconds.html#secondsBetween%28org.joda.time.ReadableInstant,%20org.joda.time.ReadableInstant)

cserepj