Re: Two unexpected test failures.

[Gary Houston <ghouston at arglist dot com>]

> From: Jim Blandy <jimb@red-bean.com>
> Date: 29 Mar 2000 22:05:33 -0500
> 
> > This test uses something like:
> > 
> > (strftime "%Z" #(47 27 21 29 2 100 3 88 1 -3600 "ZOW"))
> > 
> > What does that return on Solaris?
> 
> It returns "EST" or whatever the current time zone is.
> 
> The problem is that `struct tm' doesn't have any time zone fields on
> Solaris, so it's difficult for scm_strftime to control what strftime
> will emit for %Z.
> 
> I think there used to be code in there to temporarily set the "TZ"
> environment variable, but that was always a hack-and-a-half.  I'd
> rather simply say "We don't support this on all systems" than do that.

I think it's only the GNU C library that has time zone fields in
struct tm, so the problem may be a bit widespread to be comfortably
ignored. 

There seem to be at least two ways to fix it for the non-GNU cases: a)
the TZ hack b) including a copy of strftime.c from the GNU C library
into the Guile distribution.  It has some sort of fall-back mode where
it can process the zone fields and GNU extentions itself and pass the
rest to the underlying system strftime (including the locale support).

It seems to me that a) is the easier hack.  It's already used in a few
other places in stime.c to normalise weird interfaces.  I think the
only thing required of the TZ setting is that it has the right name,
so "TZ=EST0" or something would be good enough.

A disadvantage it that it's necessary to disable thread switching or
interrupts while TZ is hacked.  Maybe this isn't a big deal for
something like strftime.