PATCH - timezone weirdness

[Goran Thyni <goran at kirra dot net>]

Replying to self:
If one checks the environment first before messing around
with struct and getting thing wrong thing will succeed. 
The patch below is simple 
and fixes the problem on Debian GNU/Linux (sid/x86):

----------- patch --------------------------------------------------------

*** natTimeZone.cc.~1.4.~	Tue May 14 19:18:05 2002
--- natTimeZone.cc	Tue May 14 19:19:04 2002
***************
*** 31,36 ****
--- 31,37 ----
  #endif
  
  #include <string.h>
+ #include <stdlib.h>
  
  /*
   * This method returns a time zone string that is used by init_properties
***************
*** 46,51 ****
--- 47,55 ----
    long tzoffset;
    const char *tz1, *tz2;
    char *tzid;
+ 
+   tzid = getenv("TZ");
+   if (tzid) return JvNewStringUTF (tzid);
  
    current_time = time(0);
  
----------- patch --------------------------------------------------------
 


On Sat, May 11, 2002 at 07:30:12PM +0200, Goran Thyni wrote:
> 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?
>