JDK-4953991 : java.sql.TimeStamp results in wrong time for some timezones when dates are in BC
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 1.3.1_04
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2003-11-13
  • Updated: 2014-11-19
  • Resolved: 2008-12-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other Other Other
1.2.2_018 018Fixed 1.2.2_18Fixed 1.3.1_11Fixed
Related Reports
Relates :  
Relates :  
Description
Oracle engineering have found a problem with the Sun JVM or API's that cause the time to be incorrect for some timezones when the date is in BC. This impacts their application server product.

In our testing all versions tested 1.3.1_09 and before exhibit this problem. All versions tested 1.4.0_FCS and later do not exhibit this problem. While Oracle have identified this problem against java.sql.TimeStamp it's superclass java.util.Date also exhibits this problem.

This simple test case demonstrates the problem:

import java.sql.SQLException;

public class test2 {
  static public void main(String args[])  throws SQLException {
    java.sql.Timestamp ts = new java.sql.Timestamp(-6611, 0, 1, 0, 0, 0, 0);
    System.out.println("ts.toString() "+ ts.toString());
  }
}

Then compile and run with timezone set specifically in the environment:
$ javac test2.java
$ export TZ=Australia/Queensland
$ java test2

The results were as follows:

Results from a US based machine with default TZ US/Pacifiic are:

  JDK version     TZ                      Result
  ------------------------------------------------------------------
  1.2.2           US/Pacific              4712-01-01 00:00:00.0
  1.2.2           Australia/Queensland    4712-12-31 23:00:00.0 (*)
  1.2.2           Australia/Melbourne     4712-01-01 00:00:00.0 
  1.3             US/Pacific              4712-01-01 00:00:00.0 
  1.3             Australia/Queensland    4712-12-31 23:00:00.0 (*)   
  1.3             Australia/Melbourne     4712-01-01 00:00:00.0 
  1.3.1           US/Pacific              4712-01-01 00:00:00.0 
  1.3.1           Australia/Queensland    4712-01-01 00:00:00.0
  1.3.1           Australia/Melbourne     4712-12-31 23:00:00.0 (*)
  1.4             US/Pacific              4712-01-01 00:00:00.0     
  1.4             Australia/Queensland    4712-01-01 00:00:00.0     
  1.4             Australia/Melbourne     4712-01-01 00:00:00.0     
(*) => incorrect

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.2.2_018 1.2.2_18 1.3.1_11 generic FIXED IN: 1.2.2_018 1.2.2_18 1.3.1_11 INTEGRATED IN: 1.2.2_018 1.2.2_18 1.3.1_11
17-09-2004

WORK AROUND Avoid the use of dates in BC or upgrade to 1.4.0 FCS or above JWSSE have also advised that some equivilant timezones do not exhibit this problem and can be used. For example AET in place of Australia/Sydney
17-09-2004

EVALUATION In 1.3 and earlier, the TimeZone.getOffset() call in GregorianCalendar.computeFields() uses the era value returned by internalGetEra() which treats 0 as UNSET and returns AD. This creates one hour difference between computeTime() and computeFields() calculations. Since 1.4 getOffset(int, int, int, ...) isn't used to calculate time zone offsets. ###@###.### 2003-11-17 Since Tiger the Date class no longer uses GregorianCalendar (except for extremely small and large year values which require the exactly same overflow/underflow behavior for JCK tests). ###@###.### 2003-11-17 internalSet in Calendar.java does not keep trace the changes for stamp, even in timeToFields we call internalSet. So AD is the default for era and leads to calculation error for year of BC. The other problem is that there is an error for computing dstOffset for 0:00 of year 1 AD. We began day time saving from year 1 AD (?), and the offset will make the time back to before BC. These happen with 1.3.1 and 1.2.2. ###@###.### 2003-12-03
03-12-2003