java.util.Date - Test Conversion US <-> UK

Question

I have this test code below.

Lines /// 1 /// and /// 2 /// are alternatives.

If I use line /// 2 /// the output looks buggy, seems it does not account for the fact that US Boston and UK London do not differ by 5 hours during the whole year. If I use line /// 1 /// it looks OK, seems it accounts for that fact. Why so? Where is the conceptual difference? Why is shifting both dates by 1 day like this (I mean as in /// 2 ///) incorrect?

import java.util.Calendar;
import java.util.GregorianCalendar;
import java.util.TimeZone;

public class TimeZoneExample02 {

    // private static final SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");

    public static void main(String[] args) {

        Calendar bostonTime = Calendar.getInstance(TimeZone.getTimeZone("America/New_York"));

        Calendar londonTime = new GregorianCalendar(TimeZone.getTimeZone("Europe/London"));
        londonTime.setTimeInMillis(bostonTime.getTimeInMillis());

        bostonTime.getTime();
        londonTime.getTime();

        for (int i=0; i>=-500; i--){
            bostonTime.add(Calendar.DATE, -1);
            // londonTime.setTimeInMillis(bostonTime.getTimeInMillis()); /// 1 ///
            londonTime.add(Calendar.DATE, -1); /// 2 ///

            bostonTime.getTime();
            londonTime.getTime();

            System.out.printf("Boston time: %s", getString(bostonTime));
            System.out.print(" /// ");
            System.out.printf("London time: %s\n", getString(londonTime));
        }
    }


    private static String getString(Calendar c){
        StringBuilder sb = new StringBuilder();
        sb.append(c.get(Calendar.YEAR));
        sb.append("-");
        sb.append(String.format("%02d", c.get(Calendar.MONTH) + 1));
        sb.append("-");
        sb.append(String.format("%02d", c.get(Calendar.DAY_OF_MONTH)));
        sb.append(" ");
        sb.append(String.format("%02d", c.get(Calendar.HOUR_OF_DAY)));
        sb.append(":");
        sb.append(String.format("%02d", c.get(Calendar.MINUTE)));
        sb.append(":");
        sb.append(String.format("%02d", c.get(Calendar.SECOND)));
        sb.append(".");
        return sb.toString();
    }

}

OUTPUT 1:

Boston time: 2013-10-30 18:51:12. /// London time: 2013-10-30 22:51:12.
Boston time: 2013-10-29 18:51:12. /// London time: 2013-10-29 22:51:12.
Boston time: 2013-10-28 18:51:12. /// London time: 2013-10-28 22:51:12.
Boston time: 2013-10-27 18:51:12. /// London time: 2013-10-27 22:51:12.
Boston time: 2013-10-26 18:51:12. /// London time: 2013-10-26 23:51:12.
Boston time: 2013-10-25 18:51:12. /// London time: 2013-10-25 23:51:12.
Boston time: 2013-10-24 18:51:12. /// London time: 2013-10-24 23:51:12.

OUTPUT 2:

Boston time: 2013-10-30 18:50:53. /// London time: 2013-10-30 23:50:53.
Boston time: 2013-10-29 18:50:53. /// London time: 2013-10-29 23:50:53.
Boston time: 2013-10-28 18:50:53. /// London time: 2013-10-28 23:50:53.
Boston time: 2013-10-27 18:50:53. /// London time: 2013-10-27 23:50:53.
Boston time: 2013-10-26 18:50:53. /// London time: 2013-10-26 23:50:53.
Boston time: 2013-10-25 18:50:53. /// London time: 2013-10-25 23:50:53.
Boston time: 2013-10-24 18:50:53. /// London time: 2013-10-24 23:50:53.

Tangent: it is [highly recommended](http://stackoverflow.com/questions/589870/should-i-use-java-date-and-time-classes-or-go-with-a-3rd-party-library-like-joda) to use the JodaTime library rather than java.util.Date. — Oliver Charlesworth, Jan 26 '14 at 23:50
What do you think is wrong? What is the output that you don't expect? I see nothing wrong with this code (apart from the occasional superfluous bits, of course). — Dawood ibn Kareem, Jan 26 '14 at 23:53
Yes, I've heard that a few times here on SO. But first wanted to play with Java's built-in capabilities. — peter.petrov, Jan 26 '14 at 23:53
/// 2 /// is wrong because it shows that Boston and London always have 5 hours difference which is not true for the whole year (I believe so). E.g. on 2013-10-30 the difference was just 4 hours (as London and Boston change winter/summer on different days). /// 1 /// is OK with that respect. — peter.petrov, Jan 26 '14 at 23:54
On the other hand, there's little point in using JodaTime for something that works OK in the JDK classes. Not understanding how dates and times work isn't a good reason for using a whole new library, because you'll still not understand how they work. — Dawood ibn Kareem, Jan 26 '14 at 23:55
What do you mean "/// 2 /// is wrong"? What output are you getting that you don't expect? — Dawood ibn Kareem, Jan 26 '14 at 23:59
Oops, I think I realized the conceptual difference. When shifting by 1 day it does not mean I am shifting by 24 hours (as when clock changes happen those days may have 23/25 hours). Well, still not sure what happens here. Would appreciate any clear explanation as it's too late at my location now :) Yeah, probably it's this. — peter.petrov, Jan 26 '14 at 23:59
OK, thanks everyone, still would appreciate a good academic/expert answer :) — peter.petrov, Jan 27 '14 at 00:03
FYI, to clarify, London time [changed](http://www.timeanddate.com/worldclock/clockchange.html?n=136&year=2013) with Daylight Saving Time (DST) ending on 2013-10-27 when 2 AM became 1 AM (again). — Basil Bourque, Jan 27 '14 at 00:27
@peter.petrov Since you now understand the issue completely, why don't you have a go at writing your own "good academic answer"? — Dawood ibn Kareem, Jan 27 '14 at 02:11

Basil Bourque · Accepted Answer · 2014-01-27T01:26:45.323

London DST

London time changed with Daylight Saving Time (DST) ending on 2013-10-27 when 2 AM became 1 AM (again).

Features, Not Bugs

The documentation for java.util.Calendar in its discussion at top explains that unlike set(), add() forces an immediate recomputation of the calendar's milliseconds and all fields.

Furthermore, the documentation for java.util.GregorianCalendar on the add method notes that smaller units of time are not adjusted. The doc specifically notes that HOUR is a smaller field that DAY_OF_MONTH, so it is not adjusted. Meaning that you started with an hour of 23 so you'll end up with an hour of 23, with milliseconds-since-epoch recomputed as needed.

The behaviors you see for the set and add methods are both correct. Features, not bugs.

Indirect Answer

The bundled java.util.Date, java.util.Calendar, and java.text.SimpleDateFormat are notoriously troublesome, confusing, and tricky. They have flaws in both design and implementation.

I understand your interest in "to play with Java's built-in capabilities". While that interest is generally laudable, in this specific corner of Java, it is a waste of time. Even Sun and Oracle have given up on these classes. Java 8 brings a whole new java.time.* package, defined by JSR 310, inspired by Joda-Time, and supplanting the old bundled classes.

If you cannot yet move to Java 8, use Joda-Time. Joda-Time works in multiple versions of Java, and continues to work in Java 8 as it is actively maintained.

Example Code

Some example code using Joda-Time 2.3 to get you going.

Some Notes…

A Joda-Time DateTime actually knows its own time zone. In contrast, a java.util.Date has no time zone yet its toString method applies the JVM's default time zone which creates no end of confusion.

Note in this example that dateTime_Boston and dateTime_London have the same number of milliseconds-since-epoch.

Joda-Time by default uses standard ISO 8601 format for string output, like this 2014-02-13T10:32:28.131+05:30.

The + or - at the end marks a time zone offset from UTC/GMT. Do not read this as an operand in a formula. Read this as a label saying, for example, "India has a time zone offset of +05:30, so the date-time displayed is five and a half hours ahead of UTC/GMT".

PLUS SIGN ("+") means ahead of UTC/GMT.
HYPHEN-MINUS ("-") means behind UTC/GMT.

The Z at the end is pronounced "Zulu" and is shorthand for +00:00. That means UTC/GMT time zone, that is, no time zone offset.

// Specify a time zone rather than rely on default.
DateTimeZone timeZone_Boston = DateTimeZone.forID( "America/New_York" );
DateTimeZone timeZone_London = DateTimeZone.forID( "Europe/London" );

DateTime dateTime_Boston = new DateTime( 2013, 10, 27, 22, 51, 12, timeZone_Boston );
DateTime dateTime_London = dateTime_Boston.toDateTime( timeZone_London ); 
DateTime earlier_London = dateTime_London.minusDays( 2 ); // Use '2' to get us before DST change.
DateTime earlier_UtcGmt = earlier_London.toDateTime( DateTimeZone.UTC );

Dump to console…

System.out.println( "dateTime_Boston " + dateTime_Boston );
System.out.println( "dateTime_London " + dateTime_London );
System.out.println( "earlier_London " + earlier_London );
System.out.println( "earlier_UtcGmt " + earlier_UtcGmt );

When run…

dateTime_Boston 2013-10-27T22:51:12.000-04:00
dateTime_London 2013-10-28T02:51:12.000Z
earlier_London 2013-10-26T02:51:12.000+01:00
earlier_UtcGmt 2013-10-26T01:51:12.000Z

Thank you. Your examples are using the Joda time library, right? I am pretty sure but just making sure. — peter.petrov, Jan 27 '14 at 07:58
@peter.petrov Yep, Joda-Time 2.3, that's what it says under "Example Code" heading. — Basil Bourque, Jan 27 '14 at 20:30

java.util.Date - Test Conversion US <-> UK

1 Answers1

London DST

Features, Not Bugs

Indirect Answer

Example Code