"Jean-Pierre Radley" <jpr@jpr.com> wrote in message
news:20070316230448.GA24391@jpradley.jpr.com...
> Richard typed (on Fri, Mar 16, 2007 at 09:27:35PM +0000):
> | "Richard" <aapex@att.net> wrote in message
> | news:d1zJh.143854$5j1.680@bgtnsc04-news.ops.worldnet.att.net...
> | > On a re-booted 5.0.5 with /etc/TIMEZONE TZ set to
> | > 'CST6CDT5,M3.2.0/2:00:00,M11.1.0/2:00:00' everything is fine *except*
> when
> | > running a shell command from within Foxbase. Then, within the child
> | > process running the command, the Unix time reverts to CST. I've
> confirmed
> | > that the correct TZ environment variable is exported to the child
> process,
> | > which is spawned as 'sh -c command'. Spawning a similar child process
> | > from another script works properly, so the problem only occurs when
> run
> | > from within Foxbase.
> | >
> | > Possible clue: on a fully patched 5.0.7 system, the same shell command
> | > from within Foxbase works properly, with the correct time *except* if
> the
> | > TZ variable is set to override the default DST values (i.e., set the
> same
> | > as the 5.0.5 system). Then, the same problem appears, with the time
> | > reverting to CST in the child process when run from within Foxbase.
> | >
> | > Any ideas on what is happening, and how it might be corrected?
> |
> | Well, I was wrong that the correct TZ variable was exported (*slaps the
> | forehead*). Didn't notice it before, but Foxbase takes the TZ variable
> and
> | converts it to Xenix format by replacing the first comma with a
> semicolon
> | before re-exporting it prior to executing a shell command. The date
> | function then does not recognize the format and reverts to the default!
>
> What is "Xenix format"?
>
> Why in the world should Foxbase convert an environment variable?
>
> --
> JP
> ==> http://www.frappr.com/cusm <==

Hi, JP,

man environ and damned if I know.

--
Richard