JDK-4850428 : Custom time zone is not normalized in 1.4 as it was in 1.3
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 1.4.1
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2003-04-17
  • Updated: 2003-04-18
  • Resolved: 2003-04-18
Related Reports
Relates :  
Description

Name: nt126004			Date: 04/17/2003


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

FULL OS VERSION :
Windows NT Version 4.0

A DESCRIPTION OF THE PROBLEM :
If you specify a custom timezone, the timezone is not normalized properly and
you end up with the GMT+00:00:00 timezone.
For example: I have the program:

Date now = new Date();
System.out.println(now);
SimpleDateFormat outputDate = new SimpleDateFormat("dd-MMM-yyyy HH:mm:ss");
outputDate.setTimeZone( TimeZone.getTimeZone("GMT+2:0") );
System.out.println("From date2: " + outputDate.format(now));

Under the JDK1.3.1 the result of this is:

Tue Apr 01 09:34:53 CEST 2003
  From date2: 01-Apr-2003 09:34:53

Which is what I want, but
Under the JDK1.4 the result is:

Tue Apr 01 09:35:13 CEST 2003
  From date2: 01-Apr-2003 07:35:13

When I modify the custom timezone ID to
GMT+2:00
all works fine under both JDK's.

In the docs of the TimeZone object, it says that the timezone ID's are normalized.
I quote:
"For example, TimeZone.getTimeZone("GMT-8").getID() returns "GMT-08:00". "

But apparently, the JDK1.3.1 does this in a better way then the JDK1.4


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the following program under JDK1.3.1 (i used _02) and then again under the JDK 1.4 (i used _03)

Date now = new Date();
System.out.println(now);
SimpleDateFormat outputDate = new SimpleDateFormat("dd-MMM-yyyy HH:mm:ss");
outputDate.setTimeZone( TimeZone.getTimeZone("GMT+2:0") );
System.out.println("From date2: " + outputDate.format(now));


EXPECTED VERSUS ACTUAL BEHAVIOR :
Tue Apr 01 09:34:53 CEST 2003
  From date2: 01-Apr-2003 09:34:53

Tue Apr 01 09:35:13 CEST 2003
  From date2: 01-Apr-2003 07:35:13


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.util.*;
import java.text.*;


public class TestDates {
	
	
	public static void main( String[] args ) {
		
		Date now = new Date();
		System.out.println(now);
		SimpleDateFormat outputDate = new SimpleDateFormat("dd-MMM-yyyy HH:mm:ss");
		outputDate.setTimeZone( TimeZone.getTimeZone("GMT+2:0") );
		System.out.println("From date2: " + outputDate.format(now));
	} // main method
	
} // class TestDates

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Make sure that your custom timezone ID is already normalized before you use it with the TimeZone object.
This is a bit annoying when you calculate the custom timezone ID in a web browser.

On a Date object in JavaScript, you can calculate the timezone Id starting from:

var timezoneOffset = now.getTimezoneOffset();

But make sure that you normalize the ID before using it.

Release Regression From : 1.3.1
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: 183296) 
======================================================================

Comments
EVALUATION This is not a regression bug. The custom time zone handling was clarified as 4322313. The custom time zone syntax in 1.4 is: CustomID: GMT Sign Hours : Minutes GMT Sign Hours Minutes GMT Sign Hours Sign: one of + - Hours: Digit Digit Digit Minutes: Digit Digit Digit: one of 0 1 2 3 4 5 6 7 8 9 So, two digits are required for Minutes in 1.4. ("GMT+2:00" works in 1.4.) I'm closing this bug report as "not a but". However, if this change causes a serious problem for real world applications, please reopen. ###@###.### 2003-04-18
18-04-2003