Difference in accuracy DateTime.NET vs Java

Question

I am porting some calculation procedures from .Net to Java, but in the Date classes there seems to be some accuracy issues. I may have stared at this, but I cannot understand why the results are different.

How do I process dates to get the same numbers (milliseconds) on platforms?

.Net

[Test] public void foo() { DateTime dt1 = new DateTime(2011, 2, 26, 19, 25, 24); DateTime dt2 = new DateTime(2011, 2, 28, 18, 40, 25); double millis = (dt2 - dt1).TotalMilliseconds; Assert.AreEqual(170101000, millis); } 

Java

 @Test public void foo() throws Exception { Date d1 = createDate(2011, 2, 26, 19, 25, 24); Date d2 = createDate(2011, 2, 28, 18, 40, 25); long millis = d2.getTime() - d1.getTime(); Assert.assertEquals(166501000, millis, 0.01); } private static Date createDate(int year, int month, int day, int hour, int minute, int second) { Calendar instance = Calendar.getInstance(); instance.clear(); instance.set(year, month, day, hour, minute, second); return instance.getTime(); } 

Answer 1

Wonderful!

Problem:

The Java Calendar of the month starts at 0 and . Net Datetime months start at 1 .

So you are comparing .Net February with a Java march. And, as Aryan suggested, March 27 is switching to daylight saving time in many time zones.

This is a very common problem when using Java Calendar. To avoid this, you should use named constants for the following months:

 Date d1 = createDate(2011, Calendar.MARCH, 26, 19, 25, 24); // Calendar.MARCH == 2 

Answer 2

The difference in milliseconds is 3,600,000, so exactly 1 hour. Could it be that one language uses a different time zone parameter than another, where there is a change from or to daylight saving time?

I did some more tests. The PHP result matches the C # result (only I get seconds instead of milliseconds), and the Java result matches your Java result. The problem seems to be a timezone error in Java. According to Java, the second time in DST, which is not true in my time zone (Europe / Amsterdam).

Answer 3

Are you sure the problem is with the DateTime structure, not the Double structure? From the documentation for the .NET Double data type :

Floating point values ​​and loss accuracy

Remember that a floating point number can only approximate a decimal number, and that the precision of a floating point number determines how exactly this number approaches a decimal number. By default, the Double Value contains 15 decimal digits of precision, although a maximum of 17 digits are stored internally. floating point precision has several consequences:

Since you are not returning fractional milliseconds, you can use the System.Int64 data type (long in C #). Your value is within the valid range for this data type. the maximum value for Int64 (long) is 9,223,372,036,854,775,807

Answer 4

I'm confused. You say that the second (Java) test passes? Because I actually get the same number as the first (C #) test: 170101000.

Here is my test (which passes). I chose JodaTime objects as an alternative to Date and Calendar:

 @Test public void foo() throws Exception { DateTime dt1 = new DateTime(2011, 2, 26, 19, 25, 24, 0); DateTime dt2 = new DateTime(2011, 2, 28, 18, 40, 25, 0); Duration d = new Duration(dt1, dt2); Assert.assertEquals(170101000, d.getMillis(), 0.01); Date d1 = createDate(2011, 2, 26, 19, 25, 24); Date d2 = createDate(2011, 2, 28, 18, 40, 25); long millis = d2.getTime() - d1.getTime(); Assert.assertEquals(170101000, millis, 0.01); } private static Date createDate(int year, int month, int day, int hour, int minute, int second) { Calendar instance = Calendar.getInstance(); instance.clear(); instance.set(year, month, day, hour, minute, second); return instance.getTime(); } 

Answer 5

This comes from how you subtract. In java, you subtract 2 longs that represent times. If you make an envelope from a long date to a date, it may not be that you originally set it, as there is some loss of decimal place. In .net, you subtract the actual dates and then convert to miliseconds. Thus, this result will be more accurate. If you convert time in .net to full milliseconds, then subtract it, I would put that you would find much closer results.