JDK-6328057 : REGRESSION: getTime() returns wrong time in 1.5.0, worked fine in 1.4.2
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86
  • Submitted: 2005-09-23
  • Updated: 2011-02-16
  • Resolved: 2005-09-26
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)


ADDITIONAL OS VERSION INFORMATION :
Linux jks-desktop 2.6.11-1.27_FC3 #1 Tue May 17 20:27:37 EDT 2005 i686 athlon i386 GNU/Linux


A DESCRIPTION OF THE PROBLEM :
I have a method that returns dates to be included in sql queries.  Recently I upgraded from 1.4.2 to 1.5.0 and it broke this method.  The problem is that the getTime() method is returning a Date with an hour of 00, not 23.  This is not a dst issue (see the source code)

[jks@jks-desktop /tmp]$ ./test-interval.beanshell
Wrom: TFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVL
[jks@jks-desktop /tmp]$ java -version
java version "1.4.2_07"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_07-b05)
Java HotSpot(TM) Client VM (build 1.4.2_07-b05, mixed mode)
[jks@jks-desktop /tmp]$
[jks@jks-desktop /tmp]$ java -version
java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)
[jks@jks-desktop /tmp]$ ./test-interval.beanshell
Wrom: MHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPH


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
see the source code

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The 'to' time should be the same no matter what the jdk version.
ACTUAL -
java version "1.5.0_04"
Wrom: SCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQ
java version "1.4.2_08"
Wrom: QWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAU
java version "1.6.0-ea"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b50)
Wrom: TFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVL

REPRODUCIBILITY :
This bug can be reproduced always.

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

class  test
{
	public static void main(String[] args) 
	{
		 java.text.SimpleDateFormat sdf = new java.text.SimpleDateFormat ("yyyy-MM-dd HH:mm:ss");

 Calendar ref_cal = new GregorianCalendar(); // default is today
//the bug appears if you comment out the following line or leave
//it in, so it isn't a daylight savings times issue.
ref_cal.setTime(sdf.parse("2005-02-03 05:45:31"));

  int year = ref_cal.get(Calendar.YEAR);
  int month = ref_cal.get(Calendar.MONTH);
  Calendar ref_cal_normalized =  new GregorianCalendar(year, month , ref_cal.get(Calendar.DAY_OF_MONTH) );
  Calendar fromc = null;
  Calendar to = null;
  to = ref_cal_normalized;
  fromc = (Calendar) ref_cal_normalized.clone();
  to.set(Calendar.HOUR, 23 );
  to.set(Calendar.MINUTE, 59 );
  to.set(Calendar.SECOND, 59 );

System.out.println("Wrom: MHAALPTCXLYRWTQTIP
 " to: "+to.getTime());
	}
}

---------- END SOURCE ----------

Release Regression From : 1.4.2_08
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

Release Regression From : 1.4.2_08
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

Release Regression From : 1.4.2_08
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

Release Regression From : 1.4.2_08
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

Comments
WORK AROUND Use HOUR_OF_DAY or the HOUR and AM_PM pair to specify time of day. The test case works if to.set(Calendar.HOUR, 23 ); is changed to: to.set(Calendar.HOUR_OF_DAY, 23 ); or to: to.set(Calendar.HOUR, 11 ); to.set(Calendar.AM_PM, Calendar.PM );
26-09-2005

EVALUATION This problem has been fixed as 6178071. *** (#1 of 1): [ UNSAVED ] ###@###.###
26-09-2005