I like surprises, I like puzzles, therefore I like Java Date and Calendar library. I already thought that there is nothing it could surprise me with. And I was wrong. Today it got me again. Consider the following code snippet.
Calendar calendar = Calendar.getInstance(); calendar.clear(); calendar.set(Calendar.YEAR, 1970); calendar.set(Calendar.MONTH, 0);//month is zero based calendar.set(Calendar.DAY_OF_MONTH, 1); Date date = calendar.getTime(); System.out.println(date); System.out.println(date.getTime());
The command on the line 07 prints out “Thu Jan 01 00:00:00 GMT 1970
“, the question is what does the command on the line 08 prints? If you are such looser and you do not remember the JavaDoc of java.util.Date class, here is the description of getTime() method.
Returns the number of milliseconds since January 1, 1970, 00:00:00 GMT represented by this Date object.
So to reformulate the question, what is the number of milliseconds between January 1, 1970, 00:00:00 GMT and Thu Jan 01 00:00:00 GMT 1970?
What are your guesses? Make yourself famous by adding a comment with correct explanation. And do not worry, if you do not find the solution until tomorrow evening, I will post it here.
Calendar and Date are timezone-senzitive, aren’t they? So key is in “GMT” 🙂 If ran in Czech Republic, value of 3600000 will be printed … at least I think.
Yes, -3600000 is printed. But it is printed even here in Dublin and I hope that we would get the same result everywhere on the planet. So I am afraid it has nothing to do with Czech Republic.
Just guess: Daylight saving time offset?
Indeed, the one hour difference points to timezones, daylight savings or something similar. It is tempting to rule out the daylight saving, January is usually in the winter and daylight savings are applied in the summer. The correct answer is quite surprising. The GMT from JavaDoc is not the same as the GMT used in Date, Calendar and TimeZone. The GMT from JavaDoc refers to standard time (UTC). The GMT from Date class refers to London time (British Standard Time). And as you certainly know, between years 1968 and 1972 those crazy Brits kept summer time even over the winter. Thanks to them, we have quite confusing behaviour in our Java classes. Lets hope it will get better with the new DateTime Java library. For more information you can read following bug report and nice article about British time.
Output of your code on my PC is following:
Thu Jan 01 00:00:00 GMT 1970
0
So it will not print -3600000 everywhere on the planet, as you wrote. Used Java 1.5.0_04.
Yes, it depends on Timezone. But that’s correct, not surprising behaviour. It is because you are asking what is different between already set timezone and GMT timezone.
For example, when you add these lines:
TimeZone tz = TimeZone.getTimeZone(“GMT+0:00”);
calendar.setTimeZone(tz);
the result must be on every PC 0.
When you add different number, then it depends on the difference between particular timezone and GMT.
Anyway, these “Calendar+Timezone” classes/API is so complicated. It is because there are influed by historical and political reasons. So they are very different from the rest of any APIs, where logic works.
Seriously. two words:
Joda Time
http://joda-time.sourceforge.net/