Java getting UTC+2 when it would be UTC+1

Question

Last sunday we change the time (-1h) in middle europe. I was making some tests but something does not let me sleep with the java time parser. This is the code

public static void main(String[] args) {
    String dateFormatPattern = "yyyy-MM-dd HH:mm:ss";
    String dateUtc = "2016-10-09 12:50:00";

    SimpleDateFormat dateFormatUtc = new SimpleDateFormat(dateFormatPattern);
    dateFormatUtc.setTimeZone(TimeZone.getTimeZone("UTC"));

    SimpleDateFormat dateFormatLisboa = new SimpleDateFormat(dateFormatPattern);
    dateFormatLisboa.setTimeZone(TimeZone.getTimeZone("Europe/Lisboa"));

    SimpleDateFormat dateFormatMadrid = new SimpleDateFormat(dateFormatPattern);
    dateFormatMadrid.setTimeZone(TimeZone.getTimeZone("Europe/Madrid"));

    SimpleDateFormat dateFormatParis = new SimpleDateFormat(dateFormatPattern);
    dateFormatParis.setTimeZone(TimeZone.getTimeZone("Europe/Paris"));

    System.out.println("UTC: "+dateUtc);
    try {
        Date d = dateFormatUtc.parse(dateUtc);
        System.out.println("Lisboa: "+dateFormatLisboa.format(d));
        System.out.println("Madrid: "+dateFormatMadrid.format(d));
        System.out.println("Paris: "+dateFormatParis.format(d));
    } catch (ParseException e) {
        e.printStackTrace();
    }
}

And this is the output

UTC: 2016-10-09 12:50:00
Lisboa: 2016-10-09 12:50:00
Madrid: 2016-10-09 14:50:00
Paris: 2016-10-09 14:50:00

Why the difference between UTC and Madrid time are 2 hours? Now in madrid is UTC+1.

Thanks.

Answer 1

The times are correct as the clocks changed on the 30th October at 2am

if you change you code to this

String dateUtc = "2016-11-09 12:50:00";

You get this output, giving the correct 1 hour difference.

UTC: 2016-11-09 12:50:00
Lisboa: 2016-11-09 12:50:00
Madrid: 2016-11-09 13:50:00
Paris: 2016-11-09 13:50:00

The timezone is due to the when the date object is actually referencing. So it is correct for that time

Answer 2

The accepted Answer by French is correct. The values overlapped the cutover in Daylight Saving Time (DST).

I am just pointing out that your code is using old date-time classes, now legacy, supplanted by the java.time classes.

Parse the input value as a LocalDateTime because it lacks any indicator of time zone or offset-from-UTC.

Replace the SPACE in the middle with a T to comply with ISO 8601 format used by default in the java.time classes for parsing/generating strings.

LocalDateTime ldt = LocalDateTime.parse( "2016-10-09 12:50:00".replace( " " , "T" ) );

We know from the business context that UTC is intended for this input string. So assign an offset of UTC.

OffsetDateTime odt = ldt.atOffset( ZoneOffset.UTC );

Adjust into a time zone by applying a ZoneId to get a ZonedDateTime.

ZoneId z = ZoneId.of( "Europe/Lisboa" );
ZonedDateTime zdt = odt.atZoneSameInstant( z );

---

About java.time

The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.

To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.

The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.

You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.* classes.

Where to obtain the java.time classes?

• Java SE 8, Java SE 9, Java SE 10, Java SE 11, and later - Part of the standard Java API with a bundled implementation.
  • Java 9 adds some minor features and fixes.
• Java SE 6 and Java SE 7
  • Most of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
• Android
  • Later versions of Android bundle implementations of the java.time classes.
  • For earlier Android (<26), the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….

The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.