Quoth Philip Hazel on Mon, Feb 21, 2000:
> On Mon, 21 Feb 2000, Nigel Metheringham wrote:
>
> > As for the original problem, would just killing the TZ environment
> > variable (or overriding it from one in the config file) be sufficient?
>
> I don't know. This is one of those things that needs to be tested on
> different OS. Once we are back on summer time I can try putenv("TZ=")
> and see if it works on our hosts. (On Solaris TZ gets set by default; I
> don't know if killing it reverts to GMT or to local time. While they are
> the same, I can't test!)
It depends whether you have /usr/share/lib/zoneinfo/localtime as
a hard link to, say, .../zoneinfo/Europe/London. If you do,
unsetting TZ will revert you back to local time. If you don't,
it will revert you to UTC.
> Some OS have unsetenv() which might work. It's
> another of those "no two Unixes are the same" phenomena, it seems.
Ahem. There is at least three incompatible timezone packages,
some of which suck so hard that I would better not describe them.
And there is the Linux (or is it glibc's?) timezone package
compatible with David Olson's tzcode. You can see
ftp://www.cs.huji.ac.il/pub/tz/israel to get some idea.
Vadik.
--
Real software engineers don't debug programs, they verify correctness.
This process doesn't necessarily involve execution of anything on a
computer, except perhaps a Correctness Verification Aid package.
