[PATCH] Regenerate TimeZone.java from tzdata2007a

[Jakub Jelinek]

On Tue, Feb 13, 2007 at 04:47:04PM -0700, Tom Tromey wrote:
> Tom>    at java.util.SimpleTimeZone.checkRule(SimpleTimeZone.java:441)
> 
> This is called as:
> 
> Breakpoint 5, java.util.SimpleTimeZone.checkRule(int, int, int)int (
>     this=@9e320, month=2, day=8, dayOfWeek=1)
>     at ../../../../../trunk/libjava/classpath/java/util/SimpleTimeZone.java:440
> 
> It fails here:
> 
> 	if (Math.abs(day) > (daysInMonth + 6) / 7)
> 	  throw new IllegalArgumentException("dayOfWeekInMonth out of range");
> 
> I don't understand what this test is trying to do.
> It seems to be comparing a day value against a week value.
> 
> I'm also a bit lost as to what these parameters are supposed to mean.
> According to the JDK javadoc, there is no meaning assigned when all of
> month, day, and dayOfWeek are >0.  Perhaps I'm missing a case somehow.
> 
> Anyway, you probably need to know my tzid in order to fully debug
> this:
> 
> (gdb) p tzid
> $15 = java.lang.String "MST7MDT,M3.2.0,M11.1.0"
> 
> If you can't get to it, I will do it tomorrow.  It is the end of the
> day here or I would spend some time on it now.

Then the bug isn't in the tzdata2007a update patch and as shown with:
  public static void main (String[] args)
    {
      TimeZone zx = TimeZone.getDefaultTimeZone("MST7MDT6,M3.2.0,M11.1.0");
      System.out.println (zx);
    }
neither in the tzIf reader code - MST7MDT,M3.2.0,M11.1.0 string ought to
be valid, that says you have timezone MST with standard offset GMT-7,
during daylight saving time it is called MDT with dst offset GMT-6
and changes at 02:00:00 local standard time (i.e. GMT-7) on Sun>=8 in March and
back at 02:00:00 local dst time (i.e. GMT-6) on Sun>=1 in November.
This corresponds to:
new SimpleTimeZone (-7000 * 3600, "MST",
		    Calendar.MARCH, 2, Calendar.SUNDAY, 2000 * 3600,
		    Calendar.NOVEMBER, 1, Calendar.SUNDAY, 2000 * 3600)
If java.util.TimeZone.getDefaultTimeZone(String) calls SimpleTimeZone
constructor with different arguments for this string, it is buggy.
There are 3 possibilities how to express a DST (either start of end)
transition rule, with either 4 or 5 arguments.  The first one is
always Calendar.JANUARY .. Calendar.DECEMBER - the month when the
change happens.  The third one is either 0, then the second one is the day
in that month when the change happens, i.e. 1 .. 31, or it is a day
of week number (Calendar.SUNDAY .. Calendar.SATURDAY) and then the
second argument is either 1 .. 4 (1st .. 4th dayOfWeek in that month)
or -1 (last dayOfWeek in that month).

	Jakub