Bug ID: JDK-4328097 Calendar times are 1 hour in error since daylight savings changed

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

Priority: P2
Status: Closed
Resolution: Duplicate
OS: solaris_7
CPU: sparc

Submitted: 2000-04-05
Updated: 2000-08-05
Resolved: 2000-08-05

I have confirmed a bug with PalmPilot's, at least in Arizona since we do
not use daylight savings time.  Anyone who has synced his PalmPilot
since last weekend (4/2/2000) has found that new Calender entries are being
added to the PalmPilot one (1) hour ahead of the Desktop calendar.  This
is true for Solaris 7 HW 11/99 and Solaris 8 FCS desktops.

Older entries are not affected.

This was also a bug in the old shareware software and was fixable by
changing the /etc/TIMEZONE file or using a wrapper script to set TZ
before the sync command.  

#TZ=US/Arizona
TZ=MST7

Setting the above in the /etc/TIMEZONE and then rebooting does not fix this
for "sdtpdasync".

EVALUATION vijay.balasubramanian@Eng 2000-06-30 One reason could be that Solaris_JDK_1.2.1_04c on Solaris 8 does not support US/Arizona. This will need further investigation. Vijay vijay.balasubramanian@Eng 2000-08-04 Problem statement and a short program to reproduce the bug. We are from the PDASync group and currently we are working on a bug fix relating to the daylight saving time at Arizona. Through fixing the bug, we find that Arizona doesn't use daylight saving time, which is quite different from other regions of the US. Thus during summer time Arizona should have the same time as the Pacific Standard Time. However, when we run a sample Java program (with the desktop TZ variable set to US/Arizona), which instantiates a TimeZone object by calling its getDefault() method, it returns a TimeZone object of the Mountain Standard Time. In fact it should actually return a TimeZone object with the Pacific Daylight Time (or any time zone that is one hour behind the Mountain Standard Time). Such bug causes any Java program that uses the TimeZone getdefault() method under the US/Arizona setting returns a time that is one hour ahead of the legal time. Our suggestion for the fix is to change the US/Arizona mapping so during the summer, a TimeZone object with the US/Arizona setting will return the Pacific Daylight Time while after the summer the object will stick with it's original mapping to the Mountain Standard time. Such solution is similar to the US/Pacific mapping which maps to Pacific Daylight Time during the summer and Pacific Standard Time after the summer for a TimeZone object. Following is a sample Java program that returns an incorrect time with the US/Arizona TimeZone object. on Console: setenv TZ US/Arizona Compile and run following program: /** Testing for default TimeZone * */ import java.util.*; class JavaInternal { public static void main(String[] args) { Date date; // Initialize the dafault TimeZone TimeZone tz = TimeZone.getDefault(); // Prints out name and ID of the default TimeZone System.out.println("the name of this time zone in the default locale is: " + tz.getDisplayName()); System.out.println("the ID of this time zone is: " + tz.getID() ); // Initialize the Calendar with default TimeZone Calendar calendar = Calendar.getInstance(tz); // Initialize Date with the current Calendar date = calendar.getTime(); // Prints out current Date info System.out.println("Date equals: " + date.toString()); } } The program prints the current date and time based on the default TimeZone object, which is one hour behind the legal time of Arizona.

11-06-2004

WORK AROUND Manually correcting the PalmPilot entries

11-06-2004

SUGGESTED FIX vijay.balasubramanian@Eng 2000-08-01 Since Java translates TZ=US/Arizona to Mountain Standard Time, it adds 1 hour to your appointments. A temporary solution is to set TZ to US/Pacific during daylight saving time period (April to October). Java should recognize that US/Arizona does not have day light savings. We have a similar situation with BST (British Summer Time). Vijay

11-06-2004