Bug ID: JDK-6907174 Confusing ZoneInfo details displayed for Pacific/Fiji TZ

Type: Bug
Component: core-libs
Sub-Component: java.util:i18n
Affected Version: 6,6-pool

Priority: P2
Status: Closed
Resolution: Not an Issue
OS: generic,solaris_7
CPU: generic,sparc

Submitted: 2009-12-03
Updated: 2011-01-24
Resolved: 2009-12-14

We see some problems with tztool 1.3.24

When we patch a  JDK  5 or 6 using the tool, and run this test case :
-------------------------
import java.util.*;
public class TZ {
public static void main(String args[]) {
TimeZone tz = TimeZone.getTimeZone("Pacific/Fiji");
System.out.println("tz---"+tz);
}
}
---------------------------
We get  :
tz---sun.util.calendar.ZoneInfo[id="Pacific/Fiji",offset=43200000,dstSavings=0,useDaylight=false,transitions=9,lastRule=null]
 >> Basically this does not show the DST for Fiji


Java itself works fine for other timezones showing correct DST (eg : For Israel it gives):

tz---sun.util.calendar.ZoneInfo[id="Israel",offset=7200000,dstSavings=3600000,useDaylight=true,transitions=143,lastRule=java.util.SimpleTimeZone[id=Israel,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=26,startDayOfWeek=6,startTime=7200000,startTimeMode=0,endMode=1,endMonth=8,endDay=13,endDayOfWeek=0,endTime=7200000,endTimeMode=0]]

We should get a similar result for Pacific/Fiji

EVALUATION Just to clarify, a more correct way of determing whether a timezone observes DST on at particular date can be acheived with the following code example : ======= Date date = new Date(); TimeZone tz = TimeZone.getTimeZone("Pacific/Fiji"); System.out.println("in daylight time ?" + tz.inDaylightTime(date)); =======
09-02-2010
EVALUATION Closing this out as not a defect. The API is performing as expected here.
14-12-2009
EVALUATION if we read the getDSTSavings() API detail the test program is functioning as expected. Other API methods exist to determine whether a timezone is observing DST on a given date (e.g tz.inDaylightTime(date)) No date context is given when a simple "System.out.println("tz---"+tz);" call is made. The Cu should not expect the currentDate to be used in calculating DST properties on this timezone.
10-12-2009
WORK AROUND A proposed workaround is to hack the 2009s tzdata files and make the JRE assume that Fiji will observe DST indefinitely.
04-12-2009