JDK-4705403 : API: DateFormat Should Supply Time Zone of Parsed Date
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.text
  • Affected Version: 1.4.0,5.0
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: windows_2000,windows_xp
  • CPU: x86
  • Submitted: 2002-06-20
  • Updated: 2019-04-11
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
Name: nt126004			Date: 06/20/2002


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

FULL OPERATING SYSTEM VERSION :

Microsoft Windows 2000 [Version 5.00.2195]




A DESCRIPTION OF THE PROBLEM :
The issue is that after SimpleDateFormat is used to parse a
string containing a date there is no way to retrieve the
original time zone of the parsed date.
SimpleDateFormat.parse() simply returns a java.util.Date
which does not contain time zone information.

I am asking that SimpleDateFormat somehow (exactly how this
is accomplished is a design decision) return the time zone
of the parsed date. You should note that the
SimpleDateFormat.parse() method *must* know the time zone
embedded in the string being parsed since it has to be
taken into account when generating the resulting
java.util.Date.

Let me offer a scenario where this type of functionality is
important.

We are receiving data from several clients all over the
world. When clients send this data they send a time stamp
along with the data. The time stamp represents the time the
data was generated, not when it was sent to us. It's not
enough for us to simply know the GMT time representation of
the time stamp. We *also* need to know the time zone to
which the time zone applies. This is vital!!

I have more comments in the "Source Code" section below.


This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Here's a simple program that shows SimpleDateFormat's internal time zone does
not change after a date is parsed. I am running this program in the U.S.
Central Time Zone (CDT):

import java.text.*;
import java.util.*;

public class DateTester {
  public static void main(String[] args) throws Exception {
    SimpleDateFormat sdf = new SimpleDateFormat("MMM dd, yyyy HH:mm:ss zzz");

    String dateString = "Jul 13, 1997 14:52:16 EDT";

    System.out.println("BEFORE PARSE...");
    System.out.println("  sdf.getTimeZone(): " + sdf.getTimeZone
().getDisplayName());
    Date date = sdf.parse(dateString);
    System.out.println("AFTER PARSE...");
    System.out.println("  sdf.getTimeZone(): " + sdf.getTimeZone
().getDisplayName());
   } // main()
} // DateTester


The output from this program is...
--------------------
BEFORE PARSE...
  sdf.getTimeZone(): Central Standard Time
AFTER PARSE...
  sdf.getTimeZone(): Central Standard Time
--------------------
You see, the reported time zone is always the default time zone in which the
program is run. The time zone of the date string, EDT in this case, is
unavailable.

As I mentioned earlier, the SimpleDateFormat.parse() method *must* know the
time zone since it has to be taken into account when generating the resulting
java.util.Date. Why can't you make this time zone available? We really need
this.


---------- END SOURCE ----------
(Review ID: 153497) 
======================================================================

Comments
EVALUATION The SimpleDateFormat implementation changed for 4845901. The sample program now outputs: BEFORE PARSE... sdf.getTimeZone(): Central Standard Time AFTER PARSE... sdf.getTimeZone(): Eastern Standard Time However, the usage of the Calendar instance hasn't been specified. There should be a method that returns a Calendar instance containing a TimeZone.
27-12-2006

EVALUATION Should consider this for Tiger. ###@###.### 2002-06-21
21-06-2002