FULL PRODUCT VERSION :
java version "1.5.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-b08)
Java HotSpot(TM) Client VM (build 1.5.0_01-b08, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
 customer  Windows 2000 [Version 5.00.2195]

Service Pack 4

A DESCRIPTION OF THE PROBLEM :
We have a complex tool which uses editable table cells to display times. The user  can update times using these table fields. As the tool can be used to schedule jobs globally, the Timezone for the specified data is also loaded and used in a TimeZone.setDefault() call.

Under all releases prior to 1.5, clicking in the table cell has no effect  on the value of the field. However, under 1.5.0 and 1.5.0_01, as soon as the user clicks in the cell, the time is modified to local time, adding or subtracting the time difference from the timezone that was set!

Consequently, it becomes alomost impossible for the user to enter the correct time. If they type in a value, when they try and save it the difference between local and the specified timezone is applied.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile the code fragment below using the 1.5.0 compiler:

javac t.java -source 1.4 -target 1.4

Use the 1.4JRE to launch the application. Double click in the time field (first field of the table). Although the format is changed, the absolute value does not.

Now use the 1.5 JRE or 1.5.0_01 to launch the application. Double click in the time field. The result is that your local time relative to "Europe/Paris" - the timezone set in the tool - is now displayed



EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Time should not change its value
ACTUAL -
Time changes value

ERROR MESSAGES/STACK TRACES THAT OCCUR :
No errors

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.awt.* ;
import javax.swing.* ;
import javax.swing.table.* ;
import java.util.* ;
import java.sql.Timestamp ;
import java.text.* ;

public class t
{


   public static void main( String[] args)
   {
      JFrame frm = new JFrame();
      JTable tbl ;
      Vector row ;
      Vector headers = new Vector( Arrays.asList( new String[] {"date", "comment"} ) )  ;
      Vector tableData = new Vector() ;

      DefaultTableModel dtm  = new DefaultTableModel() ;


      /* create the data vector for the table */
      /* any old date will do - since the effect is seen when trying to edit the value*/
      Timestamp ts = new Timestamp( (new Date()).getTime()) ;

      row = new Vector() ;
      row.add( ts ) ;
      row.add( "double click in the time: watch the hour value change to your current TZ value!" ) ;

      tableData = new Vector() ;
      tableData.add(row) ;

      /* set up the table data */
      dtm.setDataVector( tableData, headers ) ;



      /* print the timezone */
      System.out.println("TZ = " + TimeZone.getDefault() + "\n" ) ;

      /* now set our timezone */
      TimeZone.setDefault( TimeZone.getTimeZone("Europe/Paris") ) ;

      /* print the timezone - default *IS* set to Paris */
      System.out.println("New TZ = " + TimeZone.getDefault() + "\n" ) ;


      /*
       * create a renderer to ensure that the date is presented consistently
       *
       * ...and this is where the problem lies!
       *
       */
      
      final DefaultTableCellRenderer dateRenderer
                     = new DefaultTableCellRenderer()
		       {
			  DateFormat df = DateFormat.getDateTimeInstance(
			                   DateFormat.SHORT, DateFormat.MEDIUM);

		          protected void setValue( Object value )
			  {
// TZ for the renderer is set to Paris */
//System.out.println("Renderer's TZ = " + df.getTimeZone() + "\n" ) ;
			     if ( value instanceof Date )
			        super.setValue( df.format(value) ) ;
			     else
			        super.setValue(value) ;
			  }
		       } ;

      /* create the table, using our renderers and validation routines */
      tbl = new JTable( dtm, new DefaultTableColumnModel())
            {
	       public TableCellRenderer getCellRenderer(int row, int col)
	       {
	          return dateRenderer ;
	       }
            } ;
      
      
      tbl.createDefaultColumnsFromModel() ;

      frm.getContentPane().add( tbl ) ;
      //frm.pack() ;
      frm.setSize( new Dimension(400,50) ) ;
      frm.show() ;
      
    }

}
---------- END SOURCE ----------

Release Regression From : 1.4.2_06
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.
  xxxxx@xxxxx   2005-03-18 09:59:09 GMT

N/A

This bug doesn't seem to occur any more. It looks like the problem was that the default time zone that was set was being lost and not used during toString() of the date. Perhasp i18n has a duplicate.
Posted Date : 2005-07-29 17:17:27.0

See Comments.
Posted Date : 2005-07-30 00:46:05.0

The symptom appears to be reproducible only with Tiger on Windows. In Mustang, it's not reproducible probably because AWT/Swing changed the timing to start an event dispatch thread.

TimeZone will be fixed.
Posted Date : 2005-09-12 03:13:40.0

I chatted briefly with Jeff Nisewanger, and we seem to agree that we shouldn't be doing anything special with ThreadLocals.  If multiple threads are touching static state, they should be responsible for synchronizing access to that state.  From a security point of view, a security check should be added that checks the call stack before allowing the static state to be set.
Posted Date : 2005-11-30 00:41:23.0

Any workarounds would be appreciated. This is a show stopper for us.

This still occurs for us on 1.5.0_04-b05, our application still doesn't work properly. Any workarounds?

Workaround is to also explictly set in the event dispatch thread:
SwingUtilities.invokeLater( new Runnable()
	 {
		public void run()
	         {
                      TimeZone.setDefault(                 
TimeZone.getTimeZone("Europe/Paris") ) ;
	         } 
             } ) ;