File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Java in General and the fly likes java.util.Calendar, setTime and DST Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "java.util.Calendar, setTime and DST" Watch "java.util.Calendar, setTime and DST" New topic

java.util.Calendar, setTime and DST

Anton Litvinenko

Joined: Feb 14, 2005
Posts: 2

I am developing an application that should be dst-wise. I.e. it should make difference between regular(24h), 23h and 25h days.

(my default timezone is Europe/Helsinki, 27.March.2005 at 2:59 start daylight saving time, and 31.October.2004 at 3:59 daylight saiving time ends)

Now, the problem is the following, if i am creating a Calendar representing the 31.October.2004 at 3:00, then Calendar by default treats it like wintertime date (Sun Oct 31 03:00:00 EET 2004). To mark it as summertime i set DST_OFFSET field on Calendar instance to 360000 -> Sun Oct 31 03:00:00 EEST 2004. So far, so good!

After some time of developing i faced a vry strange thing, that could be simulated by the following testcase:

This test fails, but if line starting with XXX is uncommented, then test succeeds.

After some investigations we found that Calendar implementation has an array of flags (each element for every calendar field). Every flag may have at least 3 different values: UNSET, INTERNALLY_SET and MINIMUM_USER_STAMP. Now if i am setting DST_OFFSET by hand, then corresponding flag gets some kind of a USER_SET value and thus is never recalculated. But if i am setting time/date by setTime or setTimeInMillis, then flag of every field gets INTERNALLY_SET value and is recalculated before vital operations (for instance getTime()). This is how after line Calendar simply forgets, that date is in summertime (because of the default behavior of Calendar for this date).

My question is, has anybody already faced this problem? Or perhaps someone can suggest antoher way of handling DST is Java?

Ilja Preuss

Joined: Jul 11, 2001
Posts: 14112
Hi Anton,

welcome at the Ranch!

Your problem sounds quite weird to me, but I don't know much about Calendar anyway (besides that its code looks kinda "smelly" to me).

Sun's bug database seems to have a rather big amount of entries for this class, though - just searching for "DST_OFFSET" got me 40+ hits. You might want to do your own research at

Hope this helps...

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Anton Litvinenko

Joined: Feb 14, 2005
Posts: 2
I have already started to believe that this is not a bug... this is a feature... The problem is following: Calendar has 2 ways of expressing time by milliseconds and using fields of the calendar. Now, if i am setting any field, then millisecond representation should be re-calculated. This is the place where the 'all the magic' happens. Calendar calculates time in millis in the local time, but it has to be expressed in the UTC. So, it tries to subtract timezone offset and dst offset if possible. now, there is are two hours every year (25 hour day -> ... -> 1:00 DST -> 2:00 DST -> 3:00 DST -> 3:59 DST -> 3:00 -> 4:00 -> .. at least in my timezone) and for them without any additional information it is impossible to tell whether user wants a DST time or standart one... So, Calendar programmers decided that it is always assumed that the time is standart.

This feature gets in the game only if you use set method of Calendar. I.e. if you use add or roll methods, then everything is fine. But if you are trying to simulate set method by add method, then be careful, since

is not OK for 23 and 25 hour days ( 05:34 AM of the 25 hour day - 5 hours results in 01:34 AM -> there are 2 same hours! so the actual difference is 6 hours!). Fortunately, the following hack should work:

Stephen Colebourne

Joined: Nov 07, 2004
Posts: 4
Take a look at

We have tried to make the timezone system more predictable, and we don't hold both the time in millis and the time in fields at the same time!
I agree. Here's the link:
subject: java.util.Calendar, setTime and DST