JDK-6695566 : (tz) JCK test api/java_util/TimeZone/index.html#getDisplayName: Fails on machines with GMT timezone
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 6u7
  • Priority: P1
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: generic
  • Submitted: 2008-04-29
  • Updated: 2012-03-22
  • Resolved: 2008-05-01
Related Reports
Duplicate :  
JDK-6638110 - (tz) TimeZone.getDisplayName(...) spec is inconsistent with implementation for unavailable locales
Description
api/java_util/TimeZone/index.html#getDisplayName fails on Windows XP home and Windows XP pro
when the timezone is set to GMT with automatically adjust for 'day light savings changes' ticked.


TimeZone2010: Failed. getDisplayName(daylight, style, locale) returns wrong result : BSTexpected = ISTtime zone = sun.util.calendar.ZoneInfo[id="Europe/London",offset=0,dstSavings=3600000,useDaylight=true,transitions=242,lastRule=java.util.SimpleTimeZone[id=Europe/London,offset=0,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]]daylight = truestyle = 0locale = lll_CCC_VVVdefault locale = en_IE


Verified failure on 6u7     (jdk1.6.0_07b02) 
                    6u6 fcs (jdk1.6.0_06b02) 
                    6u5 rev (jdk1.6.0_05b16) 
                    6u4     (jdk1.6.0_04b12)
Comments
EVALUATION TimeZone.getDisplayName with an explicit Locale no longer falls back to the default Locale. This behavior change was approved as part of 4052440 (Locale Sensitive Services SPI, a.k.a. Pluggable Locales SPI) in JDK6. Please refer to its CCC request. However, the spec is unclear about the behavior in case the given Locale doesn't have localized display names for the TimeZone instance. There's CR 6638110 for the spec clarification on the method. Closing this CR as a duplicate of 6638110.
01-05-2008