Name: el35337 Date: 06/23/97


Running this code:

  import java.util.*;
  
  class ttime
  {
      static void dp (String s)
      {
          System.out.println(s);
      }
      public static void main(String[] args)
      {
  
          Date now = new Date();
          dp("now is " + now.toString());
          dp("now is " + now.toGMTString());
          dp("now is " + now.toLocaleString());
          dp("now's TZ offset is " + now.getTimezoneOffset());
          dp("now.getTime is " + now.getTime());
          dp("currentTimeMillis " + System.currentTimeMillis());
          dp("Date.UTC 4/15 4:44 " + Date.UTC(97, 3, 15, 4, 44, 0));
          dp("Date.UTC 4/15 3:44 " + Date.UTC(97, 3, 15, 3, 44, 0));
          dp("Date.UTC 4/14 23:44 " + Date.UTC(97, 3, 14, 23, 44, 0));
      }
  }

at precisely 11:44:00 PM on 14-Apr-97 in EDT I get this output:

  c:\Howard\Java>java ttime
  now is Mon Apr 14 20:44:00 PDT 1997
  now is 15 Apr 1997 04:44:00 GMT
  now is 14-Apr-97 8:44:00 PM
  now's TZ offset is 240
  now.getTime is 861075840721
  currentTimeMillis 861075840852
  Date.UTC 4/15 4:44 861075840000
  Date.UTC 4/15 3:44 861072240000
  Date.UTC 4/14 23:44 861057840000

I know that in 1.1.1 Date.toString will now correctly
print the time in EDT. Someone else tried this code on
1.1.1 and had the same problems, but I ran this code
on 1.1 so that's what I'm reporting it under.

I also know that some of these
routines are deprecated but I saw worse problems in Calendar
that I have already reported. We have not switched to 1.1.1
yet because of problems mostly in AWT, I don't know if the
other Calendar problems have been fixed yet
(namely that they don't recalculate fields properly). Also
since the Date functions are layered on Calendar these problems
reflect problems in those classes.

I note the following problems:

  11:44PM EDT is in fact 20:44 PDT, that's fine.

  11:44PM EDT should be 03:44 GMT (the next day), not 04:44
  So I conclude that toGMTString is not tracking DST.

  I don't know where toLocaleString is broken but I know it's
  deprecated.
 
  TZ offset it being computed correctly. In EDT there is
  only a 4 hour difference to GMT. I don't know why the GMT
  routines don't also realize this.

  Both System.currentTimeMillis() and Date().getTime()
  return the same correct value, which it good. However
  all places that convert that to a time string seem to
  get the DST adjustment incorrectly.
 
  To be clear, if you do the
  math I think you'll find that 861075840 seconds from the
  epoch will be 3:44am Tue Apr 15, 1997 GMT. I did the math by
  hand and with Emacs' Calc package (which seems to do the
  math properly).

  The static routine Date.UTC is also broken in this way.
  That is, I would expect the 2nd call to Date.UTC() to have
  returned 861075840000 (which the first call did).

Here is some other code I've used to test things:

  // GMT shouldn't have DST set to anything other than 1
  TimeZone tz = TimeZone.getTimeZone("GMT");
  Date d = new Date();
  System.out.println("\nA new TimeZone for GMT");
  System.out.println("tz.useDaylightTime() is " + tz.useDaylightTime());
  System.out.println("tz.getRawOffset() is " + tz.getRawOffset());
  System.out.println("tz.getOffset() is " +
                     tz.getOffset(now.get(Calendar.ERA),
                                  now.get(Calendar.YEAR),
                                  now.get(Calendar.MONTH),
                                  now.get(Calendar.DAY_OF_MONTH),
                                  now.get(Calendar.DAY_OF_WEEK),
                                  now.get(Calendar.MILLISECOND)));

When I run it I get this output:

  A new TimeZone for GMT
  tz.useDaylightTime() is true
  tz.getRawOffset() is 0
  tz.getOffset() is 3600000
  TimeZone IDs for Offset 0

useDaylightTime should be false and getOffset should return
zero, not 1 hour.

Finally, running this code:

  now = new GregorianCalendar(TimeZone.getTimeZone("GMT"));
  System.out.println("DST_OFFSET: "+
                     (now.get(Calendar.DST_OFFSET)/(60*60*1000)));

Results in this output:

  DST_OFFSET: 1

and DST should be 0. It seems that parts of the system confuse
London time which is GMT during "standard" dates and BST during
"daylight savings" dates with GMT which never changes due to DST.



company - SilverStream Software , email - ###@###.###
======================================================================