java.util.Calendar, setTime and DST

[Anton Litvinenko]

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:

  
  public void testCalendarDstBug() throws Exception {
    Calendar calendar = Calendar.getInstance(TimeZone.getTimeZone("Europe/Helsinki"));
    calendar.set(2004, Calendar.OCTOBER, 31, 2, 59, 00);
    calendar.set(Calendar.MILLISECOND, 0);
    calendar.add(Calendar.HOUR, 1);
    
    Date dstBackwardDate = calendar.getTime();
 
    Calendar result = Calendar.getInstance();
    result.setTime(dstBackwardDate);
    //XXX: result.set(Calendar.DST_OFFSET, result.get(Calendar.DST_OFFSET));
    result.set(Calendar.MILLISECOND, 0);
    
    assertTrue(calendar.getTimeInMillis() == result.getTimeInMillis());
    assertEquals(calendar, result);
  }
 

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

result.set(Calendar.MILLISECOND, 0);

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!

[Ilja Preuss]

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 http://bugs.sun.com/bugdatabase/

Hope this helps...

[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

  public static void setField(Calendar calendar, int field, int value) {
    calendar.add(field, -calendar.get(field));
    calendar.add(field, value);
  }

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:

  public static void setField(Calendar calendar, int field, int value) {
    Calendar clone = (Calendar) calendar.clone();
    calendar.add(field, -calendar.get(field));
 
    if ((field == Calendar.HOUR_OF_DAY) || (field == Calendar.HOUR)
        || (field == Calendar.MINUTE) || (field == Calendar.SECOND)
        || (field == Calendar.MILLISECOND)) {
      long dst = clone.get(Calendar.DST_OFFSET);
      dst -= calendar.get(Calendar.DST_OFFSET);
 
      if (dst != 0) {
        calendar.setTimeInMillis(calendar.getTimeInMillis() + dst);
      }
    }
 
    calendar.add(field, value);
  }

Anton

[Stephen Colebourne]

Take a look at http://joda-time.sourceforge.net.

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!