Difference between two date/times

[Tim Slattery]

I'm trying to figure out the difference between date/times. Given two
dates or Timestamps or whatever, figure out the elapsed time between
them. Maybe the later one is 2 days, 3 hours, 15 minutes, 5 seconds
later then the earlier one.

I see the add method of the Calendar object, I see compareTo, but I
don't see anything that will do what I want.

 

[John B. Matthews]

I'm trying to figure out the difference between date/times. Given two
dates or Timestamps or whatever, figure out the elapsed time between
them. Maybe the later one is 2 days, 3 hours, 15 minutes, 5 seconds
later then the earlier one.

I see the add method of the Calendar object, I see compareTo, but I
don't see anything that will do what I want.

I found this discussion of DateFormat and Apache Commons helpful:

<http://groups.google.com/group/comp.lang.java.programmer/msg/46b3a37f15c
9c8d5?hl=en>

 

[Lew]

You can find the days' difference by extracting the DAY_OF_YEAR field
from each Calendar instance. The hours within the day can be found
via the HOUR_OF_DAY field, minutes via MINUTE, and so on for SECOND
and MILLISECOND. You will have to normalize for Daylight Saving
offsets when the dates cross such a boundary, and maybe for time zones
also. By combining the information obtained via these fields and
figuring the "borrow" offsets (as when the earlier day's HOUR_OF_DAY
is larger than the later day's), you can calculate the values you
want.

For many time zones, don't make the mistake of assuming a 24-hour day
in figuring the offset. Daylight Saving/Standard Time changes can
vary the day length.

 

[Arne Vajhøj]

I'm trying to figure out the difference between date/times. Given two
dates or Timestamps or whatever, figure out the elapsed time between
them. Maybe the later one is 2 days, 3 hours, 15 minutes, 5 seconds
later then the earlier one.

I see the add method of the Calendar object, I see compareTo, but I
don't see anything that will do what I want.

I am afraid you are stuck with some DIY math:

int ms = d1.getYime() - d2.getTime();
int d = ms / (24 * 60 * 60 * 1000);
ms %= (24 * 60 * 60 * 1000);
int h = ms / (60 * 60 * 1000);
ms %= (60 * 60 * 1000);
int m = ms / (60 * 1000);
ms %= (60 * 1000);
int s = ms / 1000;
ms %= 1000;

Arne

 

[Lew]

I am afraid you are stuck with some DIY math:

int ms = d1.getYime() - d2.getTime();
int d = ms / (24 * 60 * 60 * 1000);

This will yield the wrong answer for certain pairs of dates in certain time zones.

Not all days are 24 hours long in the face of Daylight Saving / Standard Time
switchovers.

 

[Arne Vajhøj]

This will yield the wrong answer for certain pairs of dates in certain
time zones.

Not all days are 24 hours long in the face of Daylight Saving / Standard
Time switchovers.

It depends on the definition of "day". The above will work
if the definition of day is a 24 hour unit. The above will not
work if a day is from time T day D to time T day D+1.

If indeed it is the last definition, then there are other
funny things to consider like the possibility of a negative
number of minutes.

Arne

 

[neuneudr]

I am afraid you are stuck with some DIY math:

Wouldn't the following give the exact same (broken) result, without
the fugly DIY math ?

Given two Calendar named cal1 and cal2:

long diff = Math.abs( cal2.getTimeInMillis() - cal1.getTimeInMillis
() );
Calendar cal3 = new GregorianCalendar();
cal3.setTimeInMillis( diff );

System.out.println("Year(s) elapsed: " + (cal3.get( Calendar.YEAR ) -
1970) ); // The epoch starts in 1970
System.out.println("Month(s) elapsed: " + cal3.get
( Calendar.MONTH ) );
System.out.println("Day(s) elapsed: " + (cal3.get
( Calendar.DAY_OF_MONTH ) - 1) ); // Days are numbered starting from
one

etc.

Driss,

 

[Arne Vajhøj]

Wouldn't the following give the exact same (broken) result, without
the fugly DIY math ?

Given two Calendar named cal1 and cal2:

long diff = Math.abs( cal2.getTimeInMillis() - cal1.getTimeInMillis
() );
Calendar cal3 = new GregorianCalendar();
cal3.setTimeInMillis( diff );

System.out.println("Year(s) elapsed: " + (cal3.get( Calendar.YEAR ) -
1970) ); // The epoch starts in 1970
System.out.println("Month(s) elapsed: " + cal3.get
( Calendar.MONTH ) );
System.out.println("Day(s) elapsed: " + (cal3.get
( Calendar.DAY_OF_MONTH ) - 1) ); // Days are numbered starting from
one

Yes.

If you remember to set timezone to GMT, then you will get the
correct result.

But I don't think it is very nice to treat a time interval as a
point in time that just happen to have the same textual
representation.

Arne

 

[Daniel Pitts]

Yes.

If you remember to set timezone to GMT, then you will get the
correct result.

But I don't think it is very nice to treat a time interval as a
point in time that just happen to have the same textual
representation.

Arne

The problem, as I see it, is that Java (arguably) has library support
for "time points", but not "time lengths". I've seen this problem with
units other than time too. Libraries often treat reference (aka
relative) angles as the same value-type as absolute angles. There is
just some math you can't do with absolutes without first converting them
to relative values. Same goes for time.

 

[Arne Vajhøj]

The problem, as I see it, is that Java (arguably) has library support
for "time points", but not "time lengths". I've seen this problem with
units other than time too. Libraries often treat reference (aka
relative) angles as the same value-type as absolute angles. There is
just some math you can't do with absolutes without first converting them
to relative values. Same goes for time.

It is something that is missing in Java.

C# has both DateTime and TimeSpan.

Arne

 

[Dr J R Stockton]

In any sensible application, the sign of the difference will matter.
One should not shove it under the carpet at this level with ABS.

The clean way is to subtract the absolute times, then convert to
standard fixed-length seconds, minutes, hours, days with simple
arithmetic along the lines of
X = ms/1000
S = X mod 60
X = (X - S)/60
then similar with 60, 24. Anything else seems likely to be inefficient
and more trouble to get assuredly always right.

Avoid months if at all possible; if not, either get a decision from
above on how it should be done or issue su7ch an edict to those below.
There is no really sensible way of doing it.

 

[John W Kennedy]

It is something that is missing in Java.

....which is why it's being added in Java 7, as part of a whole new time
system obsoleting both Date and Calendar.

 

[Arne Vajhøj]

...which is why it's being added in Java 7, as part of a whole new time
system obsoleting both Date and Calendar.

They say they will use Joda as basis.

And Joda got Duration, so that part is OK.

But in general I don't really like Joda.

Arne

 

[John W Kennedy]

They say they will use Joda as basis.

And Joda got Duration, so that part is OK.

But in general I don't really like Joda.

JavaDoc for the thing can be found at
<URL:https://jsr-310.dev.java.net/nonav/doc-2008-04-20/index.html>
I imagine it's not finished, as the only non-Gregorian calendar
supported in this version is the one used by Egyptian Christians.

 

[Roedy Green]

I'm trying to figure out the difference between date/times. Given two
dates or Timestamps or whatever, figure out the elapsed time between
them. Maybe the later one is 2 days, 3 hours, 15 minutes, 5 seconds
later then the earlier one.

see http://mindprod.com/jgloss/time.html
http://mindprod.com/jgloss/calendar.html

The question has many different answers. See the "Christmas" examples
to explain the complexities.
--
Roedy Green Canadian Mind Products
http://mindprod.com
PM Steven Harper is fixated on the costs of implementing Kyoto, estimated as high as 1% of GDP.
However, he refuses to consider the costs of not implementing Kyoto which the
famous economist Nicholas Stern estimated at 5 to 20% of GDP

 

[Stefan Ram]

I'm trying to figure out the difference between date/times. Given two

Here is an example showing how this can currently be done
with »ram.jar« (

http://www.purl.org/stefan_ram/pub/ram-jar

): Say, we would like to get the difference in seconds between
1784-02-14T02:29:21.574572+01:00 and
2108-08-16T05:49:31.346257+02:00 using
a proleptic astronomical calendar that does not take leap
seconds into regard:

public class Main
{
public static void main( final java.lang.String[] args )
throws java.text.ParseException
{
final de.dclj.ram.system.gregorian.Instant instant =
new de.dclj.ram.notation.iso8601.Instant
( "1784-02-14T02:29:21.574572+01:00" ).getGregorian();

final de.dclj.ram.system.gregorian.Instant instant1 =
new de.dclj.ram.notation.iso8601.Instant
( "2108-08-16T05:49:31.346257+02:00" ).getGregorian();

java.lang.System.out.println
( instant1.bigFloatValue().minus( instant.bigFloatValue() )); }}

/* The output is:

10240309209.771685

*/