0

I have the following code:

import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.Date;

public class CalendarTest {

    public static void main(String[] args) {

        try {

            Calendar calendar = Calendar.getInstance();

            Date _date = new SimpleDateFormat("ddMMyyyy").parse("13102014");
            Date _time = new SimpleDateFormat("hhmmss").parse("201100");

            calendar.setTimeInMillis(_date.getTime() + _time.getTime());

            System.out.println(calendar.getTime()); // NOK 1 hour less

        } catch (ParseException e1) {
            // TODO Auto-generated catch block
            e1.printStackTrace();
        }
    }
}

Why does it produce:

Mon Oct 13 19:11:00 CEST 2014

Instead of:

Mon Oct 13 20:11:00 CEST 2014

Justin
  • 1,972
  • 13
  • 28
perencia
  • 1,498
  • 3
  • 11
  • 19

4 Answers4

4

UTC versus DST

Because java.util.Date works in UTC. But its toString method confusingly applies your JVM’s current default time zone when generating a String representation of the date-time value.

I imagine your JVM’s current default time zone is in Daylight Saving Time (DST), thus the hour adjustment.

24-Hour Time

Also, your hour-of-day code should be HH for 24-hour time, not hh for 12-hour time.

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

I would say that it's possible to produce the desired output with a simple change. No JODA or Java 8 needed. I don't understand why you wrote it the way you did.

package cruft;

/**
 * CalendarTest description here
 * @author Michael
 * @link  https://stackoverflow.com/questions/26348140/java-date-calendar-giving-different-results-as-expected
 * @since 10/13/2014 4:16 PM
 */
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.Date;

public class CalendarTest {

    public static void main(String[] args) {

        try {

            Calendar calendar = Calendar.getInstance();

            Date _date = new SimpleDateFormat("ddMMyyyy hhmmss").parse("13102014 201100");

            calendar.setTimeInMillis(_date.getTime());

            System.out.println(calendar.getTime()); 

        } catch (ParseException e1) {
            e1.printStackTrace();
        }
    }
}

Here's the output I get:

"C:\Program Files\Java\jdk1.7.0_45\bin\java" -Didea.launcher.port=7536 "
Mon Oct 13 20:11:00 EDT 2014

Process finished with exit code 0
duffymo
  • 305,152
  • 44
  • 369
  • 561
1

When you parse only the time on a separate line from the date, it treats it as though that time occurs on Jan 1st 1970. Which is in the winter when you are on standard time. So when you combine the two together you get a value that's in standard time, one hour behind the current clock-on-the-wall time which is in Daylight time.

Affe
  • 47,174
  • 11
  • 83
  • 83
0

Joda-Time

The java.util.Date and .Calendar classes are notoriously troublesome. Avoid them. Use a competent date-time library instead. In Java that means either:

  • Joda-Time
    The venerable library used by many people for many years as a replacement for j.u.Date/Calendar.
  • java.time
    Bundled with Java 8, inspired by Joda-Time, defined by JSR-310, described in The Tutorial)

In Joda-Time, a DateTime object knows its own assigned time zone (unlike j.u.Date).

That string format in your Question is annoyingly bad. If possible, replace with ISO 8601 standard strings. The standard strings are much more readable and intuitive. Furthermore, both Joda-Time and java.time parse and generate standard strings by default.

Example code using Joda-Time 2.5. We do not know your time zone, so I am arbitrarily choosing Berlin. I assume your input string represents a moment in that time zone, though your Question is ambiguous.

Parse input string.

String input = "13102014201100";
DateTimeZone timeZone = DateTimeZone.forID( "Europe/Berlin" );
DateTimeFormatter formatter = DateTimeFormat.forPattern( "ddMMyyyyHHmmss" );
DateTimeFormatter formatterBerlin = formatter.withZone( timeZone );
DateTime dateTimeBerlin = formatterBerlin.parseDateTime( input );

Adjust to another time zone. In this case, UTC.

DateTime dateTimeUtc = dateTimeBerlin.withZone( DateTimeZone.UTC );

Dump to console.

System.out.println( "input: " + input );
System.out.println( "dateTimeBerlin: " + dateTimeBerlin );
System.out.println( "dateTimeUtc: " + dateTimeUtc );

When run.

input: 13102014201100
dateTimeBerlin: 2014-10-13T20:11:00.000+02:00
dateTimeUtc: 2014-10-13T18:11:00.000Z
Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
  • 1
    You could have adjusted the same matter in your previous answer. – joey rohan Oct 13 '14 at 20:21
  • Just for the note, java.time is better that Joda-time. – joey rohan Oct 13 '14 at 20:25
  • @joeyrohan Yes, I could have done one answer, as I've done in [many dozens of my other date-time Answers](http://stackoverflow.com/search?q=java+date+basil). But the first was short and sweet. This second answer is an alternative approach. – Basil Bourque Oct 13 '14 at 20:42
  • @joeyrohan No, java.time is *not* better than Joda-Time, nor is java.time a superset of Joda-Time. Do some more work and you will soon find that java.time and Joda-Time each have their strengths and weaknesses, each has features the other lacks. And check out the [`threeten-extra`](https://github.com/ThreeTen/threeten-extra) project that fills in some of the features missing in java.time. Furthermore, java.time has had some small bugs in its initial releases whereas Joda-Time is well-worn with years of usage. – Basil Bourque Oct 13 '14 at 20:43
  • Please have a look at the link, in which sir skeet (inventor of joda-time) clear out's this point in the recent edit :http://stackoverflow.com/questions/589870/should-i-use-java-date-and-time-classes-or-go-with-a-3rd-party-library-like-joda – joey rohan Oct 13 '14 at 20:47
  • 1
    @joeyrohan (a) No, I don't believe Jon Skeet invented Joda-Time, though he did drive the .Net port, Noda Time. The main force behind Joda-Time is Stephen Colebourne ([JodaStephen](http://stackoverflow.com/users/38896/jodastephen)). (b) I eagerly tried to adopt java.time in my own work but found dead-ends or missing features. I've not yet bothered to document them but there are differences between the capabilities of two libraries. That's just a fact, not opinion or insult. (c) Arguing about which is "better" is silly, like whether Honda vs Toyota is "better". Both are *excellent* and valuable. – Basil Bourque Oct 13 '14 at 20:57
  • yeah, I will look into java.time :) – joey rohan Oct 13 '14 at 21:02