[PATCH] libjava time zone fixes and improvements

[Jakub Jelinek <jakub at redhat dot com>]

Hi!

The following patch adds a new class, gnu.java.util.ZoneInfo which
unlike java.util.SimpleTimeZone can handle historical (and future)
DST transitions and different offsets and changes to java.util.TimeZone
to read /usr/share/zoneinfo files to create the TimeZone objects
preferrably over the builtin simple timezones.  The advantage of using
system tzdata files over including our own files or current hardcoded
tables (which are only SimpleTimeZone and thus can't describe some rules
for anything but one year, in other cases e.g. only next year and onwards
or only last few years correctly) is that no separate step is needed to
keep libgcj's timezone information up to date (which changes often even
20 times a year), while libgcj's own files would mean updating system
zoneinfo files and libgcj files and the current hardcoded tables mean
libgcj has to be recompiled.
In addition to this a bunch of bugs have been fixed:

 1) Date.parse wasn't able to properly parse seconds (and sometimes
    minutes) in strings like:
    Sun Mar 11 03:30:59 2007
    while Sun JDK did the right thing - the number 59 was considered
    to be a year and then overwritten again with 2007, so it got
    parsed like 03:30:00.
 2) if /etc/localtime is a symlink, try to figure zone name from where
    the symlink points to (PR28550)
 3) added /etc/sysconfig/clock parsing (PR17002)
 4) getDefaultTimeZone couldn't properly handle e.g. EST5 or EST5EDT6
 5) parseTime forgotting minutes if time was with one colon like 12:45
    (would do the right thing for 12 or 12:45:03)
 6) several SimpleTimeZone bugs, see attached SimpleTimeZoneTest.java
    testcase; e.g. set{Start,End}Rule is documented to set the time
    in WALL_TIME mode, while it was using whatever was the last mode
    set, getOffset didn't properly handle the case when millis + dstSavings
    crossed a day boundary, etc.

TimeZoneTest.java checks in all available time zones the interesting
times zdump -v computes (second before and second on which each transition
is made) - can take several minutes, as 550 or so zdump -v calls are quite
slow (as zdump uses binary searching to find the interesting times).

Ok to commit?

	Jakub

Attachment: libjava-zoneinfo.patch
Description: Text document

Attachment: TimeZoneTest.java
Description: Text document

Attachment: SimpleTimeZoneTest.java
Description: Text document