Anton Litvinenko

Greenhorn
+ Follow
since Feb 14, 2005
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Anton Litvinenko

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:



Anton
19 years ago
Hey!

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?

Thanks!
19 years ago