why this date is created with a different timezone?

Question

This code:

SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-DD_HH-mm-ss");
Date date=null;
try {
  date = format.parse("2012-07-04_13-42-03");
} catch (Exception e) {
}
File file = new File("File.txt");
Date now=new Date();
Date last= new Date(file.lastModified());
System.out.println("exec:"+date+" "+date.getTime()+" "+date.getTimezoneOffset());
System.out.println(" now:"+now+" "+now.getTime()+" "+now.getTimezoneOffset());
System.out.println("last:"+last+" "+last.getTime()+" "+last.getTimezoneOffset());

gives the result:

exec:Wed Jan 04 13:42:03 CET 2012 1325680923000 -60
 now:Wed Jul 04 13:42:20 CEST 2012 1341402140349 -120
last:Mon Jul 02 17:26:37 CEST 2012 1341242797000 -120

How can I create the date from the string so I can compare It with the rest, in the same timezone?

Is the code and output right? It seems to be in a different order, plus last and exec call the same code (date.getTime()) but return different results? — matt freake, Jul 04 '12 at 11:59
I've taken the order from another place, where it prints multiple dates. — magodiez, Jul 04 '12 at 12:02
btw you should have used `dd` instead of `DD`: `SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd_HH-mm-ss");` — Andrew Butenko, Jul 04 '12 at 12:16

score 2 · Answer 1 · answered Jul 04 '12 at 11:58

Date doesn't have a time zone. What's confusing you is that Date.toString() always returns a value formatted in the system default time zone, and that's what Date.getTimeZoneOffset does as well.

Now, in your system default time zone (Central European time, by the looks of it) the offset from UTC changes over the course of the year, as does the time zone abbreviation. That's what you're seeing: the difference between "Central European" time (UTC+1) and "Central European Summer Time") (UTC+2). That's the time zone information in the current system time zone for the instant in time represented by the Date value you're converting into a string representation.

Again, the Date itself has no information about the time zone. It's just a point in time. You can set the time zone that the SimpleDateFormat uses when parsing or formatting - that's a different matter.

You should also consider using Joda Time if at all possible - it's much better than the API built into Java.

I was going to answer about the time zone difference in January and July and link to one of your answer http://stackoverflow.com/questions/6841333/why-is-subtracting-these-two-times-in-1927-giving-a-strange-result — Raymond Chenon, Jul 04 '12 at 12:05

score 1 · Accepted Answer · answered Jul 04 '12 at 12:18

Ok, so the problem wasn't the timezone, but the conversion from

2012-07-04_13-42-03

to

Wed Jan 04 13:42:03 CET 2012

the problem is in the format pattern so changing

yyyy-MM-DD_HH-mm-ss

to

yyyy-MM-dd_HH-mm-ss

since D means Day in year and d means Day in month

score 1 · Answer 3 · answered Jul 20 '21 at 18:59

java.time

The java.util Date-Time API and their formatting API, SimpleDateFormat are outdated and error-prone. It is recommended to stop using them completely and switch to the modern Date-Time API^*.

Also, quoted below is a notice from the home page of Joda-Time:

Note that from Java SE 8 onwards, users are asked to migrate to java.time (JSR-310) - a core part of the JDK which replaces this project.

Solution using java.time, the modern Date-Time API:

import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;
import java.util.Locale;

public class Main {
    public static void main(String[] args) {
        String strDateTime = "2012-07-04_13-42-03";
        DateTimeFormatter dtf = DateTimeFormatter.ofPattern("u-M-d_H-m-s", Locale.ENGLISH);
        LocalDateTime ldt = LocalDateTime.parse(strDateTime, dtf);
        System.out.println(ldt);
    }
}

Output:

2012-07-04T13:42:03

ONLINE DEMO

How to compare two `LocalDateTime`s:

You can use LocalDateTime#isAfter and LocalDateTime#isBefore to compare two LocalDateTimes.

Learn more about the modern Date-Time API from Trail: Date Time.

What went wrong with your code?

You have used D which specifies Day in year whereas you need d which specifies Day in month. Since you are comparing all the Date-Times in the same timezone, there is no problem with the timezone in this case.

^{* For any reason, if you have to stick to Java 6 or Java 7, you can use ThreeTen-Backport which backports most of the java.time functionality to Java 6 & 7. If you are working for an Android project and your Android API level is still not compliant with Java-8, check Java 8+ APIs available through desugaring and How to use ThreeTenABP in Android Project.}

why this date is created with a different timezone?

3 Answers3

java.time

How to compare two LocalDateTimes:

What went wrong with your code?

How to compare two `LocalDateTime`s: