JDK-4179464 : RFE: Customers would like to see same timezone output in Java as entered
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.text
  • Affected Version: 1.2.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: solaris_2.6
  • CPU: generic
  • Submitted: 1998-10-07
  • Updated: 1998-10-29
  • Resolved: 1998-10-29
Related Reports
Relates :  
Description
Quoting the customer:

"But sometimes it is interesting either to user or programmer to know
what timezone is used. You may want to output the date with
a timezone indicator (like 10 september 1998 kl 14.00.13 MET).
The program shall be able to get a calendar for other timezones or
maybe the user has to select the timezone to be used.
In all these cases the timezone name MUST be the name the user or
programmer exects and is used to. For us using Solaris in the
Middle Europe zone the expected timezone name is MET. That is the name
a java program must use in the communication with a user, is is the
name a programmer must get when reading the user.timezone property
and the name a programmer knows and remembers. It is fullt possible
for java to have an internal id for timezones, but in interaction
between java and human beings must the expected timezone name be used.
If this cannot be fixed, I recommend that all text ids for timezones
in java are removed and replaced with an integer number. Than all
programmes who want to work with timezones have to add suitable
translations between number and textual representation - and they
can then use textural representations suitable for human use at their
place."

So what they need/want is some way to have the following code:

// Foo2.java
import java.util.*;

public class Foo2 {
  public static void main( String args[] ) {
    Calendar now = Calendar.getInstance();
    System.out.println( "now: " + now.getTime() );
    TimeZone tz = TimeZone.getDefault();
    int offset = tz.getRawOffset();
    String zone = tz.getID();
    System.out.println("Time zone is " + zone + " offset " +
                        offset + " Display name : " + tz.getDisplayName()  );

  }
}
// End Foo2.java
on:
 $ java -version
java version "1.2fcs"
Classic VM (build JDK-1.2fcs-K, native threads, sunwjit)

Which currently shows:
$ TZ=MET java Foo2
now: Tue Oct 06 21:14:21 CEST 1998
Time zone is Europe/Paris offset 3600000 Display name : GMT+01:00

What they want to see is:

$ TZ=MET java Foo2
now: Tue Oct 06 21:14:21 MET 1998
Time zone is Europe/Paris offset 3600000 Display name : GMT+01:00

Examples from Solaris:
 27 $ TZ=Europe/Stockholm date
Tue Oct  6 20:28:02 Europe/Stockholm 1998
 28 $ TZ=MET date                
Tue Oct  6 22:28:24 MET DST 1998
 29 $ TZ=ECT date
Tue Oct  6 20:29:21 ECT 1998
 30 $ TZ=Europe/Paris date    
Tue Oct  6 20:30:09 Europe/Paris 1998

Comments
EVALUATION I believe this is another example of a common misunderstanding regarding TimeZone. TimeZone already has an internal identifier, which the customer refers to; it is a String ID (e.g., "America/Los_Angeles", "Europoe/London"). The display name of the TimeZone is taken from the DateFormatZoneData. Users who wish to modify the display name of zones should install their own DateFormatZoneData resources. Currently, this is difficult, because there is no good mechanism for end-user or end-programmer resource installation, but this is the intended route for accomplishing what this bug requests. I see no need for integer IDs or a user mapping mechanism. If there are specific problems with display names in the existing DateFormatZoneData, please file a bug with the exact problems in it, e.g., "Europe/London should be called XYZ in the de locale, not GMT". Note that the IDs should not be platform specific; it is not intended or desired that they match either Solaris, Windows, or any other platform's IDs!
11-06-2004