Odd DST Problem - SCO

This is a discussion on Odd DST Problem - SCO ; 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 ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: Odd DST Problem

  1. Odd DST Problem

    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



  2. Re: Odd DST Problem

    On Mar 13, 8:01 am, "Richard" 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


  3. Re: Odd DST Problem

    "ThreeStar" wrote in message
    news:1173802907.920672.158560@n33g2000cwc.googlegr oups.com...
    > On Mar 13, 8:01 am, "Richard" 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).



  4. Re: Odd DST Problem (solved)

    "Richard" 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?
    >
    > --
    > Richard Seeder
    >
    >


    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!



  5. Re: Odd DST Problem (solved)

    Richard typed (on Fri, Mar 16, 2007 at 09:27:35PM +0000):
    | "Richard" 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 <==

  6. Re: Odd DST Problem (solved)


    "Jean-Pierre Radley" wrote in message
    news:20070316230448.GA24391@jpradley.jpr.com...
    > Richard typed (on Fri, Mar 16, 2007 at 09:27:35PM +0000):
    > | "Richard" 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



  7. Re: Odd DST Problem (solved)

    Richard wrote:
    >
    > "Jean-Pierre Radley" wrote in message
    > news:20070316230448.GA24391@jpradley.jpr.com...
    > > Richard typed (on Fri, Mar 16, 2007 at 09:27:35PM +0000):
    > > | "Richard" 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


    Richard,

    What fix have you developed to overcome this problem?

    As a guess, I would add an explicit line in the called shell script
    that reads the TZ value from /etc/TIMEZONE to overwrite the FoxBASE
    exported value.

  8. Re: Odd DST Problem (solved)

    "Steve M. Fabac, Jr." wrote in message
    news:46014B54.6FF1A9A@att.net...
    > Richard wrote:
    >>
    >> "Jean-Pierre Radley" wrote in message
    >> news:20070316230448.GA24391@jpradley.jpr.com...
    >> > Richard typed (on Fri, Mar 16, 2007 at 09:27:35PM +0000):
    >> > | "Richard" 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

    >
    > Richard,
    >
    > What fix have you developed to overcome this problem?
    >
    > As a guess, I would add an explicit line in the called shell script
    > that reads the TZ value from /etc/TIMEZONE to overwrite the FoxBASE
    > exported value.


    Steve,

    Yes, that's exactly what I did. I cannot find any indication in the
    documentation of why it would change the TZ format.

    --
    Richard



  9. Re: Odd DST Problem (solved)

    In article <5ywMh.417$f56.2@bgtnsc05-news.ops.worldnet.att.net>,
    Richard wrote:
    >"Steve M. Fabac, Jr." wrote in message
    >news:46014B54.6FF1A9A@att.net...
    >> Richard,
    >>
    >> What fix have you developed to overcome this problem?
    >>
    >> As a guess, I would add an explicit line in the called shell script
    >> that reads the TZ value from /etc/TIMEZONE to overwrite the FoxBASE
    >> exported value.

    >
    >Steve,
    >
    >Yes, that's exactly what I did. I cannot find any indication in the
    >documentation of why it would change the TZ format.


    The exec system call converts the TZ value to XENIX format
    when exec'ing a XENIX binary.

    John
    --
    John DuBois spcecdt@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/

  10. Re: Odd DST Problem (solved)

    John DuBois wrote:

    > In article <5ywMh.417$f56.2@bgtnsc05-news.ops.worldnet.att.net>,
    > Richard wrote:
    > >"Steve M. Fabac, Jr." wrote in message
    > >news:46014B54.6FF1A9A@att.net...
    > >> Richard,
    > >>
    > >> What fix have you developed to overcome this problem?
    > >>
    > >> As a guess, I would add an explicit line in the called shell script
    > >> that reads the TZ value from /etc/TIMEZONE to overwrite the FoxBASE
    > >> exported value.

    > >
    > >Steve,
    > >
    > >Yes, that's exactly what I did. I cannot find any indication in the
    > >documentation of why it would change the TZ format.

    >
    > The exec system call converts the TZ value to XENIX format
    > when exec'ing a XENIX binary.


    Is that documented anywhere? (both the fact that it does; and what is
    meant by "XENIX format" of a TZ value vs. OSR5's "modern" ancient
    format?)

    I vaguely remember when this was implemented...

    Anyway, shouldn't the exec() system call from a XENIX binary, when
    invoking a UNIX binary, mangle $TZ in the opposite direction?

    >Bela<


  11. Re: Odd DST Problem (solved)

    "Bela Lubkin" wrote in message
    news:200703261557.aa22645@deepthought.armory.com.. .
    > John DuBois wrote:
    >
    >> In article <5ywMh.417$f56.2@bgtnsc05-news.ops.worldnet.att.net>,
    >> Richard wrote:
    >> >"Steve M. Fabac, Jr." wrote in message
    >> >news:46014B54.6FF1A9A@att.net...
    >> >> Richard,
    >> >>
    >> >> What fix have you developed to overcome this problem?
    >> >>
    >> >> As a guess, I would add an explicit line in the called shell script
    >> >> that reads the TZ value from /etc/TIMEZONE to overwrite the FoxBASE
    >> >> exported value.
    >> >
    >> >Steve,
    >> >
    >> >Yes, that's exactly what I did. I cannot find any indication in the
    >> >documentation of why it would change the TZ format.

    >>
    >> The exec system call converts the TZ value to XENIX format
    >> when exec'ing a XENIX binary.

    >
    > Is that documented anywhere? (both the fact that it does; and what is
    > meant by "XENIX format" of a TZ value vs. OSR5's "modern" ancient
    > format?)
    >
    > I vaguely remember when this was implemented...
    >
    > Anyway, shouldn't the exec() system call from a XENIX binary, when
    > invoking a UNIX binary, mangle $TZ in the opposite direction?
    >
    >>Bela<


    One would think so, but it doesn't. Displaying the TZ variable within the
    called script shows the "XENIX" format, and running just the "date" binary
    confirms the behavior. This, of course, was never a problem when TZ was in
    the simple "CST5CDT" format. Software geriatrics certainly presents some
    interesting problems.

    --
    Richard Seeder



+ Reply to Thread