timezone weirdness

[Goran Thyni <goran at kirra dot net>]

Before I submit a TR I would like some input on this
strange problem in libgcj (both HEAD and 3.1 branch)
at least on Debian GNU/Linux (sid):

I have this simple test code:

--------- snip ------------------------------------------------------------------
import java.util.TimeZone;

public class x
{
    public static void main(String args[])
    {
	System.out.println("TZ dflt:"+TimeZone.getDefault());
    }
};
--------- snip ------------------------------------------------------------------

when I run with gij and Sun J2SDK 1.3.1 I get the following:

TZ=GMT, result is fairly OK
--------- snip ------------------------------------------------------------------
bash-2.05a$ TZ=GMT gij x && TZ=GMT java x
TZ dflt:java.util.SimpleTimeZone[id=GMT0,offset=0,dstSavings=3600000,useDaylight=false]
TZ dflt:java.util.SimpleTimeZone[id=GMT,offset=0,dstSavings=3600000,useDaylight=false,startYear=0,startMode=0,startMonth=0,startDay=0,startDayOfWeek=0,startTime=0,startTimeMode=0,endMode=0,endMonth=0,endDay=0,endDayOfWeek=0,endTime=0,endTimeMode=0]
--------- snip ------------------------------------------------------------------


TZ=America/New_York (exemple of timezone "after" UTC), 
offset is OK but timezone is bogus.
It seems that the timezone is looked up from offset, which
means it will most often be wrong
--------- snip ------------------------------------------------------------------
bash-2.05a$ TZ=America/New_York gij x &&  TZ=America/New_York java x
TZ dflt:java.util.SimpleTimeZone[id=America/Jamaica,offset=-18000000,dstSavings=3600000,useDaylight=false]
TZ dflt:java.util.SimpleTimeZone[id=America/New_York,offset=-18000000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=3,startDay=1,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]
--------- snip ------------------------------------------------------------------

TZ=Europe/Stockholm (exzmámple of timezone "before" UTC),
Same problem as above,
AND the offset is reversed so we found Stockholm clockwise to be
in the middle of the Atlantic Ocean.
--------- snip ------------------------------------------------------------------
bash-2.05a$ TZ=Europe/Stockholm gij x &&  TZ=Europe/Stockholm java x
TZ dflt:java.util.SimpleTimeZone[id=Atlantic/Cape_Verde,offset=-3600000,dstSavings=3600000,useDaylight=false]
TZ dflt:java.util.SimpleTimeZone[id=Europe/Stockholm,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]
--------- snip ------------------------------------------------------------------

I think by browing some code that when we fetch system timezone in natSystem.cc
we fetch someting else (formatwise) then the system reports with getenv("TZ").
Also I wonder why all timezone information is defined in java/util/TimeZone.java
this should be fetchable from the OS (on all modern OSes at least).

Comments?

regards,
-- 
Göran Thyni
Luleĺ / Kiruna

Attachment: msg00114/pgp00000.pgp
Description: PGP signature