Name: md23716 Date: 10/14/99


Testcase:

import java.util.*;
import java.text.*;
public class TestYearWeek
{
   public static void main(String args[]) throws Exception
   {
      int year = 1999; // February 1, 1999, the sixth week year...
      int month = 1; // months are integers from 0 to 11
      int day = 1;

      System.out.println("Applying pattern 'yyyy-w' to year " year
                         ", month " month ", day " day);

      GregorianCalendar calendar = new GregorianCalendar(year, month, day);
      Date date = calendar.getTime();
      System.out.println(" Date is: " date);
      SimpleDateFormat formatter1 = new SimpleDateFormat("yyyy-w");
      String result1 = formatter1.format(date);
      System.out.println(" Formatting with 'yyyy-w' the result is: " result1);
      Date roundtripdate1 = null;
      roundtripdate1 = formatter1.parse(result1);
      System.out.println(" Round trip date from 'yyyy-w' is: " roundtripdate1);
   }
}

Formatting a date with pattern "yyyy-w" and 1999-6 produces February 1, 1999 as expected. However parsing this date with pattern "yyyy-w":
    on jdk1.1.7 produced February 1, 1999 as expected.
    on jdk1.1.8 and jdk1.2 produces January 1, 1999

The problem here has been caused by sun bug 4153860. Because of this
change the functionality of GregorianCalendar and the documentation (for java.util.Calendar) no longer match for jdk1.1.8 or Java2 and a regression has been caused.

The documentation states:
======================================================
When computing a Date from time fields, two special circumstances may
arise: there may be insufficient information to compute the Date (such as only year and month but no day in the month), or there may be inconsistent information (such as "Tuesday, July 15, 1996" -- July 15, 1996 is actually a Monday).

Insufficient information. The calendar will use default information to specify the missing fields. This may vary by calendar; for the Gregorian calendar, the default for a field is the same as that of the start of the epoch: i.e., YEAR = 1970, MONTH = JANUARY, DATE = 1, etc.

Inconsistent information. If fields conflict, the calendar will give
preference to fields set more recently. For example, when determining the day, the calendar will look for one of the following combinations of fields. The most recent combination, as determined by the most recently set single field, will be used.

 MONTH DAY_OF_MONTH
 MONTH WEEK_OF_MONTH DAY_OF_WEEK
 MONTH DAY_OF_WEEK_IN_MONTH DAY_OF_WEEK
 DAY_OF_YEAR
 DAY_OF_WEEK WEEK_OF_YEAR
==========================================================

Therefore "yyyy-w" will set the year, then w (WEEK_OF_YEAR) is the last field (above) so DAY_OF_WEEK will default to 1. However the code change to GregorianCalendar.java computeTime() includes the comment:

// <...> For groups involving a week-related field such
// as WEEK_OF_MONTH, DAY_OF_WEEK_IN_MONTH, or WEEK_OF_YEAR, both the
// week-related field and the DAY_OF_WEEK must be set for the group as a
// whole to be considered. (See bug 4153860 - liu 7/24/98.)

As 'w' does not include DAY_OF_WEEK it is ignored altogether so the time defaults to the beginning in the year set by yyyy.
 
The problem, hence, is a change in specification requiring that
DAY_OF_WEEK must be provided (no default will be presumed). This has not been reflected in the java documentation for 1.1.8 or 1.2. The sunbug that caused this was intended to fix Inconsistent information but has broken cases of Insufficient information such as "yyyy-w".

(Review ID: 96558)

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