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?
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 http://bugs.sun.com/bugdatabase/
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
posted 15 years ago
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: