Re: libjava configuration problems

[Richard Earnshaw <rearnsha at arm dot com>]

> On 24 Jan 2001, Tom Tromey wrote:
> 
> > >>>>> "Richard" == Richard Earnshaw <rearnsha@arm.com> writes:
> > 
> > Richard> Actually, this is wrong, the test did fail.  So why does
> > Richard> natSystem.cc still try to use 'timezone'?
> > 
> > It didn't used to.  However, Warren's rewrite the timezone code seems
> > to have changed this.
> > 
> > Warren, can you look into this?  I don't recall what the old code did
> > (but I'm sure cvs does :-), but it is definitely important to use the
> > results of configure.
> 
> Actually, nothing changed; it has been this way (even when the code was in
> java/util/natTimeZone.cc).  I wrote that code when I converted the
> corresponding JNI code in Classpath to a CNI routine.  Classpath doesn't
> seem to check for this issue.
> 
> Richard, I think the attached patch will do the trick.  It builds and
> doesn't cause any regressions on my x86 linux box.  Please see if it takes
> care of the problem on yours.

Thanks this compiles OK now (with a few other nit-bits -- mainly standard 
porting issues -- I'm now running the regression tests for libjava).

An idea for your final fallback (where you currently set tzoffset to 0 is 
to use difftime to get the time difference from gmtime().  Although this 
returns a double we shouldn't loose any precission since the maximum diff 
should be at most 13 Hours including DST.


> +#else
> +  // FIXME: there must be another global if neither tm_gmtoff nor timezone
> +  // is available, esp. if tzname is valid.
> +  tzoffset = 0;		
> +#endif