Re: [PATCH] Regenerate TimeZone.java from tzdata2007a

[Jakub Jelinek <jakub at redhat dot com>]

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).

	Jakub

Attachment: J1
Description: Text document

Attachment: J2
Description: Text document