-
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
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
- duplicates
-
JDK-4035146 All dates display as PST regardless of TimeZone
-
- Closed
-
-
JDK-4067813 Win32: "user.timezone" is "GMT" for Japan (must be "JST")
-
- Closed
-
-
JDK-4028749 java.util.Date and java.util.TimeZone are not reporting theTimeZone for MST
-
- Closed
-
-
JDK-4035178 Insufficient support for timezones
-
- Closed
-
-
JDK-4035490 Timezone notation inconsistent
-
- Closed
-
-
JDK-4037641 Applet freezes when retrieving a future Date()
-
- Closed
-
-
JDK-4050886 Date.toString() returns GMT timezones for TZ outside US (change from JDK1.0.2)
-
- Closed
-
-
JDK-4052467 Iceland daylight time incorrect
-
- Closed
-
-
JDK-4052638 GetTimeInstance returns wrong values in some timezones
-
- Closed
-
-
JDK-4054699 user.timezone doesn't reflect OS settings
-
- Closed
-
-
JDK-4057161 SimpleDateFormat.format() always shows time and time zones as PDT
-
- Closed
-
-
JDK-4060880 GMT does not take into account DST
-
- Closed
-
-
JDK-4064913 TimeZone.getDefault() always returns GMT as current timezone
-
- Closed
-
-
JDK-4065244 TimeZone NightMare.... The movie...
-
- Closed
-
-
JDK-4066690 TimeZone class reports Hawaii has daylight savings time, it doesn't
-
- Closed
-
-
JDK-4066956 TimeZone Strings do not match Solaris TZ strings
-
- Closed
-
-
JDK-4069859 No timezone for Moscow, Russia
-
- Closed
-
-
JDK-4069879 Timezone: NST & Locale: NZ
-
- Closed
-
-
JDK-4069880 Win95/KR: user.region must be "KR" not "KO". user.timezone is also wrong (GMT?).
-
- Closed
-
-
JDK-4071776 The default TimeZone for DateFormat is PST
-
- Closed
-
-
JDK-4080294 SimpleDateFormat improperly formats Arizona time (AZ does not obs. DST)
-
- Closed
-
-
JDK-4029456 API: strange effects with timezones whose abbrev matches a US timezone
-
- Closed
-
-
JDK-4037446 TimeZone default is wrong -- hides bugs
-
- Closed
-
-
JDK-4037469 TimeZone.getDefault doesn't function per spec
-
- Closed
-
-
JDK-4058144 Computers in US/East-Indiana Timezone return wrong Timezone Default
-
- Closed
-
-
JDK-4064494 Date.getDate() incorrect in Korean local
-
- Closed
-
-
JDK-4037093 "E" in MET means "Eastern" in Java, "Europe" in Solaris
-
- Closed
-
-
JDK-4034490 i18n: SimpleDateFormat doesn't know about timezones known to TimeZone
-
- Closed
-
-
JDK-4059431 Problem with the SystemTime on a Solaris Machine (Timezone = "WET")
-
- Closed
-
- relates to
-
JDK-4107380 Calendar.getTime() returns time GMT + 3.5 hours.
-
- Closed
-
-
JDK-4179464 RFE: Customers would like to see same timezone output in Java as entered
-
- Closed
-