Name: joT67522 Date: 12/10/97


DateFormatZoneData and LocaleElements classes
in an en_AU flavour are missing. Locale information
therefore defaults to which is incorrect for Australia.

How can you ignore Australia? We're not a state
of the US (yet).

------------------------


If you examine the classes in java.text.resources you'll see that there
are groups of similarly named files. The varying suffixes represent
different languages/countries. The files contain locale specific information
that Java uses to format data into text according to the conventions used in
different countries/ languages - for example how to format
dates/times/currency
amounts, names of days, months.

The locale for Australia is en_AU. Java will first look for a class named
LocaleElements_en_AU on my system since that is my default locale.
Since it doesn't find that it loads LocalElements_en. However that file
contains
locale information for the US. A similar process occurs when Java looks
for the DateFormatZoneDate file.

Where locale information is different from the US for Australia, Java will
format data incorrectly.

The specific problem I encountered was Java formatting a date using the US
convention (Month first ) rather than the local convention (Day first), but
I see from examining the file that currency formatting could also be a
problem,

This will likewise be a problem for people from many other countries also.
For English speakers more sensible values in LocaleElements_en would reduce
problems since the US is usually the odd one out.

People have sent in a fix, see 4069784.


rdleeper
                                  I believe that line 276 of SimpleDateFormat.java
                                  is the culprit.

                                  Calendar.getInstance(TimeZone.getTimeZone(formatData.zoneStrings[0][0]),
                                  loc);

                                  as can be seen the index of the zone strings is hard coded
                                  and therefore will never change. I am assuming the
                                  zone strings are and will always be loaded the
                                  same no matter which machine or time zone an application
                                  is run.

                                  The probable fix to this is:

                                  Calendar.getInstance(TimeZone.getDefault(), loc);

                                  However, this code is in JavaSoft's hands and therefore
                                  we are at their mercy.

                                  Fortunately, I have use the following work around
                                  whenever using a SimpleDateFormat.

                                  SimpleDateFormat sdf = new SimpleDateFormat("...");
                                  sdf.setTimeZone( TimeZone.getDefault() );

                                  Additionally, any time I retrieve the date/time
                                  instances from DateFormat, I do the above to
                                  ensure the proper format is achieved.

                                  To see what time zone your SimpleDateFormat is using,
                                  do System.out.println(sdf.getTimeZone().getID());

                                  Mon Dec 01 18:37:49 PST 1997

Hope this helps,

Andrew
(Review ID: 21338)
======================================================================