xxxxx  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  xxxxx  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

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

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.
  xxxxx@xxxxx   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).
  xxxxx@xxxxx   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.

  xxxxx@xxxxx   2003-12-03

with 1.3.1_12 we store timestamps with oracle jdbc thin 8.1.7.2 driver, and time gets shifted by one hour plus (we store 2004-08-01 12:00, and it becomes 13:00 in the database.

can it be you did something you did not intend? or did oracle driver work around it, and now this is not necessary any more?

With this bug-fix my application started to read shifted Dates/Timestamps from Borland TableDataSet connected to TextDataFile.
The dates/times are written in test files and when I read them in my application they are shifted by 1 hour.
Please check this bug-fix once more.