Name: rmT116609 Date: 04/30/2002


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 :
Microsoft 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)
======================================================================