Inconsistency with setTimestamp & getTimestamp and DST

Question

Hi,
how do I file a bug report on this website?!
Well, our customer had serious problems on their website yesterday because of
what seems to be a bug in oracle's JDBC drivers (version 8.1.7.1 against an
8.1.7 database, running on Solaris on the production system, reproduced with
linux). The example code below demonstrates the problem.
In short, I insert a timestamp value 'October 27th, 2002 02:00 MET/DST', when I
later retrieve it I get 'October 27th, 2002 02:00 MET' or one hour later. (In case
you don't know: DST was switched off during the night 26th->27th).
Bye,
     Peter
* OracleBug.java
* (C) 2002 [ t]ivano Software GmbH http://www.tivano.de/
* Created on 28. Oktober 2002, 12:57
* $Log: DataSourceTest.java,v $
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.Timestamp;
import java.sql.SQLException;
/** Test for a possible oracle bug.
* @author Peter Conrad
* @version $Id$
public class OracleBug {
/** Creates a new instance of OracleBug */
public OracleBug() {
/** Usage: OracleBug <jdbc-url> */
public static void main(String[] args) {
if (args.length != 1) {
System.err.println("Usage: OracleBug <jdbc-url>");
System.err.println("DB user, password and other properties must");
System.err.println("be provided as system properties. The Oracle");
System.err.println("JDBC driver must be mentioned in jdbc.drivers");
System.err.println();
System.err.println("Example:");
System.err.println("java -cp .:classes12.zip -Djdbc.drivers=oracle.jdbc.OracleDriver -Duser=test \\\n\t-Dpassword=test OracleBug jdbc:oracle:thin:@192.168.16.2:1521:TIVANO");
return;
Timestamp problem = new Timestamp(1035676800000L);
try {
Connection c = DriverManager.getConnection(args[0],
System.getProperties());
PreparedStatement p = c.prepareStatement("CREATE TABLE BugTest (ts DATE NOT NULL)");
p.execute();
p.close();
p = c.prepareStatement("INSERT INTO BugTest (ts) VALUES (?)");
p.setTimestamp(1, problem);
p.execute();
p.close();
p = c.prepareStatement("SELECT * FROM BugTest WHERE ts = ?");
p.setTimestamp(1, problem);
ResultSet rs = p.executeQuery();
if (rs.next()) {
Timestamp ts = rs.getTimestamp(1);
if (ts.equals(p)) {
System.out.println("Everything's OK. Hum.");
} else {
System.out.println("Gotcha! DB returns " + ts.getTime()
+ " but we gave it " + problem.getTime()
+ "!");
} else {
System.out.println("Empty ResultSet! This shouldn't happen!");
rs.close();
p.close();
p = c.prepareStatement("DROP TABLE BugTest");
p.execute();
p.close();
c.close();
} catch (Exception e) {
e.printStackTrace();

Answer 1

Hi Justin,
thanks for your patience. :-)
I forgot to mention that we're using the THIN driver, sorry.
Here's the code I'm using to generate the timestamp. It is meant to generate a
Timestamp that is unique for a particular day in our timezone. It works fine most of
the time, only on October 27th it produced the timestamp I used in the example code,
which doesn't work.
public static Timestamp makeTimestamp(Date date) {
Calendar local = Calendar.getInstance();
Calendar gmt = Calendar.getInstance(java.util.TimeZone.
getTimeZone("GMT+00"));
local.setTime(date);
gmt.clear();
gmt.set(local.get(Calendar.YEAR), local.get(Calendar.MONTH),
local.get(Calendar.DAY_OF_MONTH));
return new Timestamp(gmt.getTime().getTime());
But the important point is, I think, that the timestamp happens to be just before the
switchover from MET/DST to MET. Meanwhile I have verified that other timestamps in the
interval 2:00 AM - 3:00 AM on October 27th fail as well, while timestamps before
and after that interval work fine.
As to the support question: I'm of course prepared to pay if other people look for bugs
in my code, or generally help fix things that I've done wrong. I'm not willing to pay
them to fix something they've done wrong. So it boils down to "who's paying for
finding out whose fault it is?". I've done my best to provide a very simple example proving
that it's Oracle's fault (which has already cost me time and my employer money),
and since it should be in the best interest of Oracle to find and fix bugs in their
product I think they should at least give me a chance to prove it to them directly.
(I suppose I don't get a refund if I buy a support contract just to prove them, and it
turns out that I was right. Or do I? Will Oracle pay for the time I'm spending on
that problem? :-)
Bye,
     Peter