Name: akC97680			Date: 04/06/2000



The javadoc spec for java.util.TimeZone.getDisplayName(*, Locale) does not
specify digits symbols, which are used to represent offset in case of timezone
name is not available for the specified locale ('GMT[-+]hh:mm' format). Some
locales (for example Kanji or Hindi) has own [alternative] digit symbols. The
javadoc should clearly specify whether alternative digit symbols are allowed to
represent digits in the timezone name returned by
TimeZone.getDisplayName(*,Locale).

Following JCK tests are failing due to this problem:
api/java_util/TimeZone/index.html#getDisplayName[TimeZone2009]
api/java_util/TimeZone/index.html#getDisplayName[TimeZone2011]

Below is message from a licensee, showing the problem:

> Guys,
> 
> We support the hi_IN locale in our JDKs and this is giving us problems in
> one of the JCK-13rc1 testcases. The test in question is:
> 
> api/java_util/TimeZone/index.html#getDisplayName
> 
> This test is failing with the following output:
> 
> TimeZone2009: Failed. getDisplayName(daylight, style, locale) returns wrong
> result : GMT-??:??
> expected = GMT-11:00
> time zone =
> java.util.SimpleTimeZone[id=Pacific/Niue,offset=-39600000,dstSavings=3600000,useDaylight=false,startYear=0,startMode=0,star
> tMonth=0,startDay=0,startDayOfWeek=0,startTime=0,startTimeMode=0,endMode=0,endMonth=0,endDay=0,endDayOfWeek=0,endTime=0,end
> TimeMode=0]
> 
> 
> daylight = false
> style = 0
> locale = hi_IN
> TimeZone2010: Passed. OK
> TimeZone2011: Failed. getDisplayName(daylight, style, locale) returns wrong
> result : GMT-??:??
> expected = GMT-01:59
> time zone =
> java.util.SimpleTimeZone[id=,offset=-7200000,dstSavings=1,useDaylight=true,startYear=0,startMode=1,startMonth=0,startDay=1,
> startDayOfWeek=0,startTime=0,startTimeMode=0,endMode=1,endMonth=6,endDay=1,endDayOfWeek=0,endTime=0,endTimeMode=0]
> 
> 
> daylight = true
> style = 0
> locale = hi_IN
> 
> The problem here is that the test gets all available Locales and then does
> a getDisplayName() using all those locales. It compares the returned String
> with the default formatting, which are English style characters. You can
> see above that the first test is expecting a string "GMT-11:00" and it is
> getting "GMT-??:??".This is why the test is failing. The reason that ??:??
> is being returned is because the numeric characters in Hindi are not the
> same as English ones and the unicode characters being returned are
> interpreted on an ASCII system as the ? character. I imagine that this
> would be a problem for other Arabic locales...
> 
> The developer responsible for this wrote:
> 
> "The reason you're seeing '?' characters is because you're trying to
> display a Unicode character for a Hindi digit on an ASCII (or EBCDIC)
> terminal.  Obviously no such character exists.  The character converter, in
> trying to do a mapping it can't accomplish, just outputs a '?'.
> 
> If you look at the actual string contents (in Java) you will see that there
> are no '?' characters; that's just an output artifact."
> 
> We believe that this is a test bug and we would appreciate it if you could
> either correct or exclude the test from the JCK.
> 

======================================================================