Bug ID: JDK-4031021 Calendar.getTime() does not return localized date and time. It always returns GM

Type: Bug
Component: core-libs
Sub-Component: java.util
Affected Version: 1.1

Priority: P3
Status: Closed
Resolution: Not an Issue
OS: windows_95
CPU: x86

Submitted: 1997-02-07
Updated: 1997-07-16
Resolved: 1997-07-16


Name: mc57594			Date: 02/07/97


System.out.println("Current Time");
SimpleTimeZone mez = new SimpleTimeZone(+1 * 60 * 60 * 1000, "Berlin");
mez.setStartRule(Calendar.APRIL, 1, Calendar.SUNDAY, 2 * 60 * 60 * 1000);
mez.setEndRule(Calendar.OCTOBER, -1, Calendar.SUNDAY, 2 * 60 * 60 * 1000);
Calendar calendar = new GregorianCalendar(mez);
Date trialTime = new Date();
calendar.setTime(trialTime);
System.out.println("TIME: " + calendar.getTime());

The timevalue returned by Calendar.getTime() differs from the timefieldvalues of the Calendar-class (DATE, HOUROFDAY etc.) 
in that is does not use Calendar.ZONEOFFSET. Instead ist always returns GMT time (e.g. NOT local time).
company  -  Technical University of Berlin, Germany  , email  -  ###@###.###
======================================================================

[Sheri Good 03/06/97]  Here is a user with a the same time zone problem in
MET (Middle European Time)

From: Bjoern-Arne Meyn <###@###.###>

Subcategory: classes_util
Bug/rfe/eou: bug
Synopsis: TimeZone.getDefault() always returns GMT as current timezone
Description: On my computer running under Windows 95, the default timezone is MET (Middle European Time = GMT + 1 / +2 DST).  Java code such as the following should return MET as default timzone and a raw offset of 1 (* 60 * 60 * 1000).

SimpleTimeZone stz = (SimpleTimeZone)SimpleTimeZone                       		    .getDefault();
System.out.println(stz.getID());
System.out.println(stz.getRawOffset() / (60 * 60 * 1000));

The values returned by the code are GMT and 0, no matter what the actual timezone is. If I change the timezone in my system's configuration, to EST for example, Java fails to notice this and still returns the values above.

company -  , email - ###@###.###
Work around: 


Comments:
customer_rec: new
Company: other
Employee:Bjoern-Arne Meyn
Release: jdk11
Hardware Version: i586
O/S version: win_95
User Role: D
User Type: E
Sun Contact: (internal)
end_customer_rec: 
BUG_END

======================================================================

WORK AROUND Name: mc57594 Date: 02/07/97 Do not use Calendar.getTime(). Use the timefields of class Calendar and generate a date with the constructors of the Date class (ignore deprecation-warnings). ====================================================================== Wrong. These warnings about deprecated methods are there for a reason. Instead, use a DateFormat instance, and use its setTimeZone method to explicitly set its time zone if you care. norbert.lindenberg@Eng 1997-07-15

15-07-1997

EVALUATION I think this is fixed, in that you put in a new Date and get out local time, though not the local time of the Calendar you put the Date in (and got it from). I can't find another bug to say this one is a duplicate of. To help out, here's the example as a real Java class, and the output on JDK1.1. % cat java/B4031021.java import java.util.Calendar; import java.util.Date; import java.util.GregorianCalendar; import java.util.SimpleTimeZone; public class B4031021 { public static void main(String[] argv) { System.out.println("Current Time"); SimpleTimeZone mez = new SimpleTimeZone(1*60*60*1000, "Berlin"); mez.setStartRule(Calendar.APRIL, 1, Calendar.SUNDAY, 2*60*60*1000); mez.setEndRule(Calendar.OCTOBER, -1, Calendar.SUNDAY, 2*60*60*1000); Calendar calendar = new GregorianCalendar(mez); Date trialTime = new Date(); calendar.setTime(trialTime); System.out.println("TIME: " + calendar.getTime()); } } % /usr/local/java/jdk1.1/solaris/bin/javac -d classes -classpath classes:/usr/local/java/jdk1.1/solaris/lib/classes.zip java/B4031021.java % /usr/local/java/jdk1.1/solaris/bin/java -classpath classes:/usr/local/java/jdk1.1/solaris/lib/classes.zip B4031021 Current Time TIME: Fri Feb 07 16:38:48 PST 1997 % date Fri Feb 7 16:38:50 PST 1997 peter.kessler@Eng 1997-02-07 ---------------------------------------------------------------------------- The description actually lumps together two independent complaints. 1) The Date returned by Calendar.getTime() doesn't maintain the calendar's time zone. This is by design - Date objects live in UTC and aren't related to time zones. Only the old, deprecated routines that convert between Date and String force Date objects to get reacquainted with time zones. To get correct results, use a DateFormat instance, and use its setTimeZone method to explicitly set its time zone if you care. 2) The time zone returned as the default when running in Middle European Time is wrong. This is a valid complaint. Resolution: 1) -> not a bug 2) -> forked off as a separate bug 4064913 norbert.lindenberg@Eng 1997-07-15

15-07-1997