[PATCH] Regenerate TimeZone.java from tzdata2007a

[Andrew Haley]

Jakub Jelinek writes:
 > On Wed, Feb 14, 2007 at 03:59:45AM -0500, Jakub Jelinek wrote:
 > > 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).
 > 
 > Actually, I left out another 2 possibilities, if the third argument
 > is negative (-Calendar.SATURDAY .. -Calendar.SUNDAY), then the second
 > argument must be non-zero and, either if it is 1 .. 31 it is the
 > day of the month after or on which the change happens and below zero
 > it is before or on.
 > So, in tzdata speak, the possibilities are:
 > tzdata rule	{start,end}Day		{start,end}DayOfWeek
 > 5		5 (1 .. 31)		0				# change on 5th
 > Sun>=9		9 (1 .. 31)		-SUNDAY (-SATURDAY .. SUNDAY)	# change on Sun after or on 9th
 > Sun<=16		-16 (-31 .. -1)		-SUNDAY (-SATURDAY .. SUNDAY)	# change on Sun before or on 16th
 > Sun>=8		2 (1 .. 5)		SUNDAY (SUNDAY .. SATURDAY)	# change on 2nd Sun in month
 > lastSun		-1 (-5 .. -1)		SUNDAY (SUNDAY .. SATURDAY)	# change on last Sun in month
 > 
 > Now, getDateParams parses M3.2.0 as { Calendar.MARCH, 8, Calendar.SUNDAY }
 > which is invalid (8th Sunday in March?).  M3.2.0 can be expressed in several
 > valid ways, e.g.
 > { Calendar.MARCH, 2, Calendar.SUNDAY }		# second Sunday in March
 > { Calendar.MARCH, 8, -Calendar.SUNDAY }		# Sunday on or after 8th of March
 > { Calendar.MARCH, -14, -Calendar.SUNDAY }	# Sunday on or before 15th of March
 > 
 > Here are 2 untested patches that parse it the first and second way.
 > 
 > Branches which don't have the VMTimeZone.java changes don't need this fix
 > (at least not urgently, it could be only triggered by people using
 > the POSIX TZ strings in TZ env var or in timezone property), while
 > on the trunk and the redhat/gcc-4_1-branch-java-merge* it is urgent
 > (as readTzFile returns these strings for /etc/localtime).

OK, I see.  I didn't apply the VMTimeZone.java fixes to 4.1 and 4.2
branches and the 4.1 branch is closed anyway.

I'm testing on trunk.

Andrew.