5

I follow this question: Convert from java.util.date to JodaTime

I have date: Sun Jan 01 00:00:00 CET 1854 now I want to convert it to joda datetime:

DateTime dateTime = new DateTime(date);

and now when I print this date I got: 1853-12-31T23:57:44.000+00:57:44

what is wrong and why my date changed ? How I can get the same date ?

UPDATE:

I get date using calendar:

Calendar cal1 = Calendar.getInstance();
cal1.set(1854, 0, 1, 0, 0, 0);
cal1.getTime()

UPDATE2:

propably there is problem with milseconds:

    Calendar cal1 = Calendar.getInstance();
    cal1.set(1854, 0, 1, 0, 0, 0);
    DateTime start = new DateTime(1854, 1, 1, 0, 0, 0);
    System.out.println(start.getMillis());
    System.out.println(cal1.getTime().getTime());

because this code return:

-3660598664000
-3660598799438

but I dont know why

UPDATE3:

enter image description here

Community
  • 1
  • 1
hudi
  • 15,555
  • 47
  • 142
  • 246

5 Answers5

8

Joda-Time uses the accurate time-zone database, which has Local Mean Time (LMT) for years before time-zones started. To quote Wikipedia:

Local mean time is a form of solar time that corrects the variations of local apparent time, forming a uniform time scale at a specific longitude.

The JDK doesn't use LMT, thus the times differ.

Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
JodaStephen
  • 60,927
  • 15
  • 95
  • 117
4

ok I solve it. Is isnt nice but it works what is important

  Calendar calendar = Calendar.getInstance();
    calendar.setTime(datum);

    DateTime current = new DateTime(calendar.get(Calendar.YEAR), calendar.get(Calendar.MONTH) + 1,
            calendar.get(Calendar.DAY_OF_MONTH), 0, 0, 0);
hudi
  • 15,555
  • 47
  • 142
  • 246
0

IF you have the date as type of java.util.date you can use

java.util.Date date = ....
DateTime dateTime = new DateTime(date.getTime());
Timo Hahn
  • 2,466
  • 2
  • 19
  • 16
0

this code

Calendar cal1 = Calendar.getInstance();
    cal1.set(1854, 0, 1, 0, 0, 0);
    DateTime start = new DateTime(cal1.getTime());
    System.out.println(start);
    System.out.println(cal1.getTime());

outputs :

1854-01-01T00:00:00.941Z
Sun Jan 01 00:00:00 GMT 1854

I imagine the millisecond discrepancy is calendar choosign the saem time of day as now, to start the milliseconds count on. Whereas joda-time chooses midnight. Or something similarly obtuse. I try and stay away from java's built in Calendar and Date, they are an abomination.

NimChimpsky
  • 46,453
  • 60
  • 198
  • 311
0

The Answer by JodaStephen is correct and should be accepted.

The Joda-Time team have instructed us to migrate to the java.time framework built into Java 8 and later. So I was curious to try this problem in java.time and compare results.

The Question says the input data is for CET offset-from-UTC, but the code in the Question ignores that fact. My code below uses an offset of one hour ahead of UTC to account for CET.

java.time

The CET means one hour ahead of UTC. Since we have only an offset-from-UTC and not a full time zone, I use the OffsetDateTime class, for +01:00.

LocalDateTime localDateTime = LocalDateTime.of ( 1854 , 1 , 1 , 0 , 0 , 0 , 0 ); // The nineteenth century.
ZoneOffset offset = ZoneOffset.of ( "+01:00" );  // “CET” means one hour ahead of UTC.
OffsetDateTime odt = OffsetDateTime.of ( localDateTime , offset );
Instant instant = odt.toInstant ();  // A moment on the timeline in UTC, with resolution in nanoseconds.
long m = instant.toEpochMilli ();

System.out.println ( "odt: " + odt + " | millis: " + m );

odt: 1854-01-01T00:00+01:00 | millis: -3660598800000

Joda-Time

Same code, but using Joda-Time 2.9.3.

DateTimeZone zone = DateTimeZone.forOffsetHoursMinutes ( 1 , 0 );
DateTime dateTime = new DateTime ( 1854 , 1 , 1 , 0 , 0 , zone );
long millis = dateTime.getMillis ();

System.out.println ( "dateTime: " + dateTime + " | millis: " + millis );

dateTime: 1854-01-01T00:00:00.000+01:00 | millis: -3660598800000

Result is same as java.time.

java.util.Calendar

For comparison only. Normally you should avoid the old java.util.Date/.Calendar classes as they have proven to be poorly designed, confusing, and troublesome.

Calendar calendar = Calendar.getInstance ();
calendar.set ( 1854 , 0 , 1 , 0 , 0 , 0 );
TimeZone zone = TimeZone.getTimeZone ( "GMT+01:00" );
calendar.setTimeZone ( zone );
long millis = calendar.getTimeInMillis ();

System.out.println ( "calendar: " + calendar + " | millis: " + millis );

calendar: java.util.GregorianCalendar[time=-3660598799715,areFieldsSet=true,areAllFieldsSet=false,lenient=true,zone=sun.util.calendar.ZoneInfo[id="GMT+01:00",offset=3600000,dstSavings=0,useDaylight=false,transitions=0,lastRule=null],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=1854,MONTH=0,WEEK_OF_YEAR=1,WEEK_OF_MONTH=1,DAY_OF_MONTH=1,DAY_OF_YEAR=1,DAY_OF_WEEK=1,DAY_OF_WEEK_IN_MONTH=1,AM_PM=0,HOUR=0,HOUR_OF_DAY=0,MINUTE=0,SECOND=0,MILLISECOND=285,ZONE_OFFSET=3600000,DST_OFFSET=0] | millis: -3660598799715

Different results. Here we have -3660598799715 versus -3660598800000 in java.time & Joda-Time, a difference of 285.

Europe/Brussels

I also tried all three with a time zone of Europe/Brussels rather than an offset-from-UTC.

In java.time. Using ZonedDateTime class rather than OffsetDateTime.

LocalDateTime localDateTime = LocalDateTime.of ( 1854 , 1 , 1 , 0 , 0 , 0 , 0 ); // The nineteenth century.
ZoneId zoneId = ZoneId.of ( "Europe/Brussels" );
ZonedDateTime zdt = ZonedDateTime.of ( localDateTime , zoneId );
Instant instant = zdt.toInstant ();  // A moment on the timeline in UTC, with resolution in nanoseconds.
long m = instant.toEpochMilli ();

System.out.println ( "zdt: " + zdt + " | millis: " + m );

zdt: 1854-01-01T00:00+00:17:30[Europe/Brussels] | millis: -3660596250000

In Joda-Time. Only first line is different.

DateTimeZone zone = DateTimeZone.forID ( "Europe/Brussels" ); 

dateTime: 1854-01-01T00:00:00.000+00:17:30 | millis: -3660596250000

In java.util.Calendar. Some code except for the TimeZone line:

TimeZone zone = TimeZone.getTimeZone ( "Europe/Brussels" ); 

calendar: java.util.GregorianCalendar[time=-3660598799151,areFieldsSet=true,areAllFieldsSet=false,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Europe/Brussels",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=184,lastRule=java.util.SimpleTimeZone[id=Europe/Brussels,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=1854,MONTH=0,WEEK_OF_YEAR=1,WEEK_OF_MONTH=1,DAY_OF_MONTH=1,DAY_OF_YEAR=1,DAY_OF_WEEK=1,DAY_OF_WEEK_IN_MONTH=1,AM_PM=0,HOUR=0,HOUR_OF_DAY=0,MINUTE=0,SECOND=0,MILLISECOND=849,ZONE_OFFSET=3600000,DST_OFFSET=0] | millis: -3660598799151

All three using Europe/Brussels differ from their version with offset of +01:00.

And again java.time & Joda-Time agree with each other (-3660596250000), while differing from Calendar (-3660598799151), a difference of 2,549,151 (about 42 and a half minutes).

Community
  • 1
  • 1
Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154