FULL PRODUCT VERSION :
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

FULL OPERATING SYSTEM VERSION :
 customer  Windows 2000 [Version 5.00.2195]

A DESCRIPTION OF THE PROBLEM :
On Windows the behaviour of java.sql.Timestamp is impacted by the "Automatically adjust clock for daylight savings time" setting when the TimeZone is set to GMT and it shouldn't be.  For example, creating a Timestamp instance by passing it milliseconds or a string will result in different times based on whether or not "Automatically adjust clock for daylight savings time" is selected or
not.  The specific Timestamp string I was seeing problems with was "1968-12-18 10:15:30.4".  I'll give details in the steps to reproduce.

REGRESSION.  Last worked in version 1.3.1_03

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.  Create a small java app with the following code:

		String javaVersion = System.getProperty( "java.version" );
		System.out.println( javaVersion );
		
		Timestamp ts1 = Timestamp.valueOf("1968-12-18 10:15:30.4");
		long ms;
		if ( javaVersion.startsWith( "1.3" ) )
			ms = (ts1.getTime() + (ts1.getNanos()/1000000));
		else
			ms = ts1.getTime();
		System.out.println( "ms1 : " + ms );
		System.out.println( "ts1 : " + ts1 );
		Timestamp ts2 = new Timestamp( ms );
		if ( javaVersion.startsWith( "1.3" ) )
			ms = (ts2.getTime() + (ts2.getNanos()/1000000));
		else
			ms = ts2.getTime();
		System.out.println( "ms2 : " + ms );
		System.out.println( "ts2 : " + ts2 );
		System.out.println( "date: " + new java.util.Date( ms ) );

2.  Set the TimeZone to GMT and select "Automatically adjust clock for daylight savings time".

3.  Invoke the java app with JDK 1.3.1_03 and you'll receive a correct value of -32708669600 for milliseconds.

4.  Invoke the java app with JDK 1.4.0 and you'll receive an incorrect value of -32712269600 for milliseconds.

5.  Unselect "Automatically adjust clock for daylight savings time".

6.  Invoke the java app with JDK 1.4.0 and you'll receive a correct value of -32708669600 for milliseconds.

Results:

With JDK1.3.1_03(checking the "Automatically adjust clock for daylight savings time"):

C:\>java TimestampBug
1.3.1_03
ms1 : -32708669600
ts1 : 1968-12-18 10:15:30.4
ms2 : -32708669600
ts2 : 1968-12-18 10:15:30.4
date: Wed Dec 18 10:15:30 GMT 1968

With JDK1.3.1_03(unchecking the "Automatically adjust clock for daylight savings time"):

C:\>java TimestampBug
1.3.1_03
ms1 : -32708669600
ts1 : 1968-12-18 10:15:30.4
ms2 : -32708669600
ts2 : 1968-12-18 10:15:30.4
date: Wed Dec 18 10:15:30 GMT 1968

With JDK1.4.0(checking the "Automatically adjust clock for daylight savings time"):

C:\>java TimestampBug
1.4.0
ms1 : -32712269600
ts1 : 1968-12-18 10:15:30.4
ms2 : -32712269600
ts2 : 1968-12-18 10:15:30.4
date: Wed Dec 18 10:15:30 GMT 1968


With JDK1.4.0(unchecking the "Automatically adjust clock for daylight savings time"):

C:\>java TimestampBug
1.4.0
ms1 : -32708669600
ts1 : 1968-12-18 10:15:30.4
ms2 : -32708669600
ts2 : 1968-12-18 10:15:30.4
date: Wed Dec 18 10:15:30 GMT 1968

EXPECTED VERSUS ACTUAL BEHAVIOR :
In all cases I expected to receive a value of -32708669600 for milliseconds.

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.sql.*;
import java.io.*;


class TimestampBug
{	
	public static void main(String[] args)
	{
		String javaVersion = System.getProperty( "java.version" );
		System.out.println( javaVersion );
		
		Timestamp ts1 = Timestamp.valueOf("1968-12-18 10:15:30.4");
		long ms;
		if ( javaVersion.startsWith( "1.3" ) )
			ms = (ts1.getTime() + (ts1.getNanos()/1000000));
		else
			ms = ts1.getTime();
		System.out.println( "ms1 : " + ms );
		System.out.println( "ts1 : " + ts1 );
		Timestamp ts2 = new Timestamp( ms );
		if ( javaVersion.startsWith( "1.3" ) )
			ms = (ts2.getTime() + (ts2.getNanos()/1000000));
		else
			ms = ts2.getTime();
		System.out.println( "ms2 : " + ms );
		System.out.println( "ts2 : " + ts2 );
		System.out.println( "date: " + new java.util.Date( ms ) );
	}
}
---------- END SOURCE ----------

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

(Review ID: 146049) 
======================================================================
Posted Date : 2005-10-18 18:26:36.0

N/A

Requires investigation, will target for Mantis if fix required.


  xxxxx@xxxxx   2002-05-28

Under investigation...

  xxxxx@xxxxx   2003-11-12

Under consideration for JDBC 4.0

  xxxxx@xxxxx   2004-02-06
This should be fixed if possible for mustang and then backported to tiger
Posted Date : 2006-05-10 20:26:26.0

Deferring this bug to next release of jdk.
Posted Date : 2006-07-20 18:02:17.0

I'm experiencing a similar problem on JDK 1.4.  I set a new 
Timestamp using a long GMT millis value (1035694800000).  I 
store it in a database in a datetime field.  I immediately 
perform a SELECT and retrieve the value back into a new 
Timestamp object.  getTime() now returns 1035698400000 
which is one hour later.  I've tried this with Oracle, 
Informix, and MySql, all with the same results.  If I turn 
off "Automatically adjust clock for daylight savings time" 
in Windows, I now get the correct date and time back.

 Similiarly, on Windows XP, jdk1.4.1: - the time is off by one 
hour when "Automatically adjust clock for daylight savings" is 
off.  (Which is the default with dell box's, I believe)

System.out.println(new Date(System.currentTimeMillis
()).toString());

I am experiencing a similar problem to gcristof, but I'm using VAJ which is 1.2 compliant.
There seem to be two issues here:
1. java.sql.Timestamp uses different rules for reading a timestamp from and writing a timestamp to a DB.
2. an absolute milliseconds value is being interpreted as a local time and not an absolute time.
I need an absolute time to be written to the DB. In particular, when I write new Timestamp(0) into the DB, I expect to see 1/1/1970 00:00:00 not something with Daylight saving or local timezone deltas applied.
Steve Flasby

I am also having the similar issue with the timestamp, I have 
been unable to come up with a suitable work around.

I'm having the same problem with JDK 1.4.2.  It only happens
when a timestamp gets serialized between two windows
machines (XP SP1 in my case) and one has automatically
adjust for GMT set and the other one doesn't.  This is a
really serious problem for us since we pass timestamps back
to our Swing GUI client which then reports all the dates as
-1 hour.

Has the bug been resolved in the later relase of jdk? And so, which jdk version is it? 
Otherwise, what's the plan on the bug resolution from sun?

The bug here is in ever applying daylight time corrections to GMT. However that misnaming of the UK civil timezone is an historic mistake in Java and unlikely to be corrected for compatibility reasons.
The surprising behaviour and apparent regression stems from two features:
First, starting with 1.4, Java implemented historically correct timezone offsets.
Secondly, between 1968 and 1971 the UK operated on British Standard Time, which was 1 hour ahead of GMT (UTC) throughout. Most unfortunately this period includes the Unix/Java epoch date of 1970-01-01 00:00.
This code:
Timestamp ts3 = Timestamp.valueOf("1970-01-01 00:00:00");
System.out.println("ts3="+ts3.getTime());

prints 
ts3=-3600000

The behaviour is of course unchanged with the latest version (1.6 u10 as I write this).

Whoops, GMT did get fixed. But the UK civil timezone is not GMT (well it has the same offset for part of the year).
So adding 
		TimeZone.setDefault(TimeZone.getTimeZone("GMT"));

before the test code will give the correct result. The problem arises when using a time zone of "Europe/London".

Very annoying bug. I create a java.sql.Time from a string with valueOf and then take the long provided by getTime() and use it to create java.sql.Timestamp or a java.util.Date and I am missing one hour. Please get this fixed. 7 years and it seems to survive to every new release.

This is a very annoying bug indeed. It needs to be fixed.

I have exactly the same problem on Linux with java.sql.Time, very annoying.

The solution is using Calendar to get milliseconds  value like this:
java.sql.Time time;

Calendar cal = new Calendar()
cal.setTime(time);
long ms = cal.getTimeInMillis();

Getting a milliseconds from 'time' to set Calendar makes the bug to appear. 

It looks like this bug will never be fixed because of compatibility reasons.

Please remove my previous comment.  My workaround does not work too. Sorry