JDK-6228060 : No hour 0 on April 15 1990.
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-02-11
  • Updated: 2010-07-29
  • Resolved: 2005-02-12
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
java version "1.4.2_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_01-b06)
Java HotSpot(TM) Client VM (build 1.4.2_01-b06, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [版本 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
It is impossible to represent any minute between April 15 1990 00:00:00 to April 15 1990 01:00:00 using Calendar class.
In addition if a Calendar object is set to April 14 1990 00:00:00 and the object is increased one day by invoking add(Calendar.DAY_OF_MONTH, 1), the result will be April 14 1990 23:00:00.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
compile the folloing code and

java tt 04/14/1990

//------------------------------------------------------------------------------------------
import java.util.*;
import java.text.*;

public class tt
{
	static void showCalendar(Calendar cal)
	{
		System.out.println(	cal.get(Calendar.YEAR) + "/" +
							(cal.get(Calendar.MONTH) + 1)+ "/" +
							cal.get(Calendar.DAY_OF_MONTH) + "-" +
							cal.get(Calendar.HOUR_OF_DAY) + ":" +
							cal.get(Calendar.MINUTE) + ":" +
							cal.get(Calendar.SECOND) + "/" +
							cal.get(Calendar.DAY_OF_WEEK) + "-" +
							cal.getTimeZone().getID());
	}
	public static void main(String[] args)
	{
		try
		{
			DateFormat df = new SimpleDateFormat("MM/dd/yyyy");
			Date d = df.parse(args[0]);
			Calendar cal = Calendar.getInstance(TimeZone.getTimeZone("PRC"));
			cal.set(1990, 3, 15, 0, 59, 0);
			showCalendar(cal);
			cal.setTime(d);
			showCalendar(cal);
			cal.set(Calendar.HOUR_OF_DAY, 4);
			showCalendar(cal);
			cal.set(Calendar.HOUR_OF_DAY, 0);
			showCalendar(cal);
			cal.add(Calendar.DAY_OF_MONTH, 1);
			showCalendar(cal);
			cal.set(Calendar.HOUR_OF_DAY, 4);
			showCalendar(cal);
			cal.set(Calendar.HOUR_OF_DAY, 0);
			showCalendar(cal);
		}
		catch(Exception e)
		{
		}
	}
}

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
1990/4/15-0:59:0/1-PRC
1990/4/14-0:0:0/7-PRC
1990/4/14-4:0:0/7-PRC
1990/4/14-0:0:0/7-PRC
1990/4/15-0:0:0/7-PRC
1990/4/15-4:0:0/7-PRC
1990/4/15-0:0:0/7-PRC
ACTUAL -
1990/4/15-1:59:0/1-PRC
1990/4/14-0:0:0/7-PRC
1990/4/14-4:0:0/7-PRC
1990/4/14-0:0:0/7-PRC
1990/4/14-23:0:0/7-PRC
1990/4/14-4:0:0/7-PRC
1990/4/14-0:0:0/7-PRC

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.util.*;
import java.text.*;

public class tt
{
	static void showCalendar(Calendar cal)
	{
		System.out.println(	cal.get(Calendar.YEAR) + "/" +
							(cal.get(Calendar.MONTH) + 1)+ "/" +
							cal.get(Calendar.DAY_OF_MONTH) + "-" +
							cal.get(Calendar.HOUR_OF_DAY) + ":" +
							cal.get(Calendar.MINUTE) + ":" +
							cal.get(Calendar.SECOND) + "/" +
							cal.get(Calendar.DAY_OF_WEEK) + "-" +
							cal.getTimeZone().getID());
	}
	public static void main(String[] args)
	{
		try
		{
			DateFormat df = new SimpleDateFormat("MM/dd/yyyy");
			Date d = df.parse(args[0]);
			Calendar cal = Calendar.getInstance(TimeZone.getTimeZone("PRC"));
			cal.set(1990, 3, 15, 0, 59, 0);
			showCalendar(cal);
			cal.setTime(d);
			showCalendar(cal);
			cal.set(Calendar.HOUR_OF_DAY, 4);
			showCalendar(cal);
			cal.set(Calendar.HOUR_OF_DAY, 0);
			showCalendar(cal);
			cal.add(Calendar.DAY_OF_MONTH, 1);
			showCalendar(cal);
			cal.set(Calendar.HOUR_OF_DAY, 4);
			showCalendar(cal);
			cal.set(Calendar.HOUR_OF_DAY, 0);
			showCalendar(cal);
		}
		catch(Exception e)
		{
		}
	}
}
---------- END SOURCE ----------
###@###.### 2005-2-11 02:10:10 GMT

Comments
EVALUATION The issue involves two different problems. One is that time zone PRC (an alias of Asia/Shanghai) is defined in the public time zone database (aka Olson public source) as follows. # From Shanks: # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Shang 1940 only - Jun 3 0:00 1:00 D Rule Shang 1940 1941 - Oct 1 0:00 0 S Rule Shang 1941 only - Mar 16 0:00 1:00 D Rule PRC 1949 only - Jan 1 0:00 0 S Rule PRC 1986 only - May 4 0:00 1:00 D Rule PRC 1986 1991 - Sep Sun>=11 0:00 0 S Rule PRC 1987 1991 - Apr Sun>=10 0:00 1:00 D # Zhongyuan Time ("Central plain Time") Zone Asia/Shanghai 8:05:52 - LMT 1928 8:00 Shang C%sT 1949 8:00 PRC C%sT According to this data, China observed daylight saving time from 1986 until 1991. However, the comments for those rules say that: # Shanks writes that China has had a single time zone since 1980 May 1, # observing summer DST from 1986 through 1991; this contradicts Devine's # note about Time magazine, though apparently _something_ happened in 1986. # Go with Shanks for now. I made up names for the other pre-1980 time zones. "Shanks" refers to: # Thomas G. Shanks, The International Atlas (5th edition), # San Diego: ACS Publications, Inc. (1999). So, if there's any evidence that the time zone data for China is wrong, please report it to the time zone mailing list (###@###.###). The other problem is that the daylight saving time handling code didn't deal with transitions at midnight correctly. This problem was fixed in Tiger as 4958050. The correct output should be: $ java -showversion tt 4/14/1990 java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64) Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode) 1990/4/15-1:59:0/1-PRC 1990/4/14-15:0:0/7-PRC 1990/4/14-4:0:0/7-PRC 1990/4/14-0:0:0/7-PRC 1990/4/15-1:0:0/1-PRC 1990/4/15-4:0:0/1-PRC 1990/4/15-1:0:0/1-PRC The following is from the output of the zdump command on Linux that uses the same time zone data. ... Asia/Shanghai Sat Apr 14 15:59:59 1990 UTC = Sat Apr 14 23:59:59 1990 CST isdst=0 gmtoff=28800 Asia/Shanghai Sat Apr 14 16:00:00 1990 UTC = Sun Apr 15 01:00:00 1990 CDT isdst=1 gmtoff=32400 ... This is consistent with the fix. Closing this CR as a duplicate of 4958050. ###@###.### 2005-2-12 01:41:43 GMT
12-02-2005