-
Enhancement
-
Resolution: Won't Fix
-
P5
-
None
-
1.3.0, 1.4.0, 5.0, 6
-
generic, x86, sparc
-
generic, linux, solaris_7, windows_xp
For example, TZ=XST7XDT8,0/0:00,0/1:00 is mapped to America/Denver which has the different DST schedule. (This TZ value is used in a regression test and this wrong result is taken as a correct behavior.)
- duplicates
-
JDK-4976874 TimeZone.getDefault() should reflect startDayOfWeek and endDayOfWeek of TZ
- Closed
-
JDK-4976879 Arbitrarily defined timezones like GMT-11 as GMT+11 are mis-interpreted
- Closed
-
JDK-6992725 SimpleDateFormat.format(Date) is an hour late for MEZ-1MESZ,M3.5.0,M10.5.0
- Closed
-
JDK-4703351 No DST offset recognized in class Calendar when specified in TZ env var
- Closed
-
JDK-6211541 TimeZone class doesn't support all Time Zones
- Closed
- relates to
-
JDK-8249642 Java display an hour off from system date when TZ env var is set on linux
- Closed
-
JDK-6466476 (tz) Introduction of tzdata2005r can introduce incompatility issues with some JDK1.1 3-letter TZ Ids
- Closed
-
JDK-4494025 RFE: Need PSARC/2001/383 support
- Resolved