Details
-
Bug
-
Resolution: Duplicate
-
P3
-
None
-
1.1, 1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.1.5, 1.2.0
-
generic, x86, sparc
-
generic, solaris_2.5, solaris_2.5.1, solaris_9, windows_95, windows_nt
Description
Name: sg39081 Date: 08/05/97
Here is what you do. I am running Solaris 2.5 and JDK 1.1.2
compile /usr/share/lib/zoneinfo/northamerica with zic.
set your timezone environment variable like this:
TZ=America/Managua;export TZ
Run HotJava-1.0 and observe that the time reported on the
hotjava clock is one hour later than the actual time in Managua.
The ideal behavior would be to display the correct time.
As a person living and working in Managua I find this to be a
bit anoying. Not that I use hotjava that much, but I am using
java for other things and would like to be able to determine the
local time using java.
company - , email - ###@###.###
======================================================================
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
Attachments
Issue Links
- duplicates
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
JDK-4034490 i18n: SimpleDateFormat doesn't know about timezones known to TimeZone
-
- Closed
-
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-