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 - ###@###.###
======================================================================
- duplicates
-
JDK-4069784 TimeZone.getDefault() returns incorrect time zome.
-
- Closed
-