"ThreeStar" <sco@3starsoftware.com> wrote in message
news:1173802907.920672.158560@n33g2000cwc.googlegr oups.com...
> On Mar 13, 8:01 am, "Richard" <a...@att.net> wrote:
>> 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?
>>
>> --
>> Richard Seeder
>
> Isn't that Foxbase old Xenix code? The extended format for TZ was
> introduced for the 1987 changes in daylight savings time. If memory
> serves Xenix either was never updated to handle that or its TZ had
> some other format.
>
> Part of MP5 to 5.0.7 was some library changes incorporating the new
> and historic TZ rules. So that's probably why it's working there in
> the absence of an explicit TZ. No such patch was made for 5.0.5.
>
> --RLR
>

Doesn't explain why it does not work with the TZ change in 5.0.7. Remember,
this is a shell command that is being executed, not Foxbase code (in which,
the date functions work correctly).