From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10135 invoked from network); 24 Jul 1997 14:56:42 -0000 Received: from euclid.skiles.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 24 Jul 1997 14:56:42 -0000 Received: (from list@localhost) by euclid.skiles.gatech.edu (8.8.5/8.8.5) id KAA08270; Thu, 24 Jul 1997 10:44:05 -0400 (EDT) Resent-Date: Thu, 24 Jul 1997 10:44:05 -0400 (EDT) Date: Thu, 24 Jul 1997 18:44:35 +0400 (MSD) From: Andrej Borsenkow X-Sender: bor@itsrm1 Reply-To: borsenkow.msk@sni.de To: "C. v. Stuckrad" , rene@math.fu-berlin.de cc: Zsh workers list Subject: Re: Possible Bug / strange behaviour / Version 3.0.2 Solaris 2.4 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"nCIti.0.912.qesrp"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/3376 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Thu, 24 Jul 1997, C. v. Stuckrad wrote: > > As this does NOT happen under LINUX and NOT under SunOS > it might be something spuriously depending on the OS and on the > ZSH-Version but we found it extremely strange: > > In Solaris 2.4 (compiled with gcc 2.7.2) the zsh 3.0.2 > switches the time depending on 'how the TZ-variable was created' > > - If exported directly, or exported and a command follows > the shown value of '%*' changes. > - If just set, or 'exported by just exporting the variable and no command > on the line' the time stays correct! > > Any ideas? It smells like a OS bug. I can reproduce it as well (probably, because my system also originates in SVR4 ;-) This happens (in my OS at least) under very special cases. I can describe it, if you are interested. It has nothing to do with ZSH - I can send you small test program which shows this problem. As for your description - untill TZ is exported, time functions, which are used by ZSH, just don't see it and use some fallback value (UTC in our case -- obviously MET in your case). If you export empty TZ - it is the same, as unset it. As soon as TZ is exported, it triggers this bug. Just interseted: on my system exporting full TZ specification is buggy, but exporting just "TZ=CET-1CEST-2,M3.5.0/02:00:00" works fine. OTOH who needs to change TZ on the fly ;-} greetings ------------------------------------------------------------------------- Andrej Borsenkow Fax: +7 (095) 252 01 05 SNI ITS Moscow Tel: +7 (095) 252 13 88 NERV: borsenkow.msk E-Mail: borsenkow.msk@sni.de -------------------------------------------------------------------------