markus@etn-rad.UUCP (Markus N. Richardson) (10/09/87)
We are having problems *encouraging* cron to accept our (PST8PDT) timezone.
So far we have done the following to try to alleviate the problem:
Placed the line "TZ=PST8PDT; export TZ" at the beginning of /etc/rc
Placed the line "TZ=PST8PDT; export TZ" at the beginning of /etc/profile
Placed the line "setenv TZ PST8PDT" in /etc/cshprofile (our csh startup file)
None of these have solved the problem. All cron jobs still execute based
on the default timezone (EST)! Any good ideas?
FYI, we are running 5v2r2 UNIX. Please e-mail any responses as this is
(hopefully :-) a simple problem that probably has been hashed out before.
Thanks in advance.
--
Markus N. Richardson
Research and Development
Eaton Corporation IMSD
Westlake Village, CA 91359
{ voder,ihnp4,trwrb,scgvaxd,jplgodo }!wlbr!etn-rad!markus
markus@etn-rad.eaton.combrad@bradley.UUCP (10/12/87)
put the TZ in the shell script that cron executes.
vix@ubvax.UUCP (Paul Vixie) (10/12/87)
In article <290@etn-rad.UUCP> markus@etn-rad.UUCP (Markus Richardson) writes: > >We are having problems *encouraging* cron to accept our (PST8PDT) timezone. >So far we have done the following to try to alleviate the problem: My Cron (PD) allows TZ (and any other env vars of your choice) to be set in each crontab (one per user, for you BSD-only folks). Cron does not use the variable itself, in interpreting time ranges in the crontabs; however, all processes created by cron will inherit the proper value. Letting TZ differ on a per-crontab basis is of questionable use, but that's how it is.. Vixie's PD Cron is available via mail from several sources - it was posted to comp.sources.misc some months back, and that group is not officially archived. I need to rewrite it quite a bit, which is why it didn't go into comp.sources.unix... It also needs to be ported to SysV - that's right, it's BSD-only at present. I was hoping that someone else would do this, but it looks like it's up to me. It shouldn't be much work, though - a few hours at most. (Hint Hint - I don't have a SysV machine, so testing is hard!) -- Paul Vixie Consultant Work: 408-562-7798 vix@ubvax.ub.com Ungermann-Bass Home: 415-647-7023 ames!pyramid!ubvax!vix Santa Clara, CA <<I do not speak for Ungermann-Bass>>
michael@macom1.UUCP (John Michael Mullins) (10/19/87)
in article <290@etn-rad.UUCP>, markus@etn-rad.UUCP (Markus N. Richardson) says: > > > We are having problems *encouraging* cron to accept our (PST8PDT) timezone. > So far we have done the following to try to alleviate the problem: > [edited] > None of these have solved the problem. All cron jobs still execute based > on the default timezone (EST)! Any good ideas? We had the same problem at our site. This function did work under System III, but after much phone time with AT&T support, they say the TZ variable is not a supported function of cron. My opinion of the situation is that it was intended to be supported, but it's one of those problem bugs that someone made an executive decision "to let it be" One of the things I noticed about this bug, or "lack of feature" is that when I try to set the TZ variable as you mentioned, the actual time reported by the executed program, is not consistent. One day it will execute at 2100, report that the time is 0600, then the next day, it will again run at 2100, but the reported time may be 0820 (or something equally off the wall). Unless someone with source knows better, I would say you/we are stuck on this. -- John Michael Mullins CENTEL Business Information Systems, Inc. 5515 Security Lane, Rockville, Maryland, 20852, (301) 984-3636 UUCP: michael@macom1.UUCP or decuac!macom1!michael
rwhite@nusdhub.UUCP (Robert C. White Jr.) (10/21/87)
In article <1588@macom1.UUCP>, michael@macom1.UUCP (John Michael Mullins) writes: > in article <290@etn-rad.UUCP>, markus@etn-rad.UUCP (Markus N. Richardson) says: > > [Timezone Problem in AT&T UNIX] > [An echo of the above, with refrences to bad Customer service] Our [the only one at the time] 3B2 had the same problem. I work fairly closley with some AT&T people, and was told that the cron thing had been overlooked for SVR2 or below. The newest releases SVR3.1 [I dont know about 3.0] support TZ Correctly. There were several TZ munges in cron. As near as I could figure, the older cron just does not deal with it's environment at all. My fix was to prepend . /etc/TIMEZONE ; to every cron line and add three hours to the hours field [when used] It's ugly, but the programs [especially uudemon.hour (as in poll)] appreciate the prepend greatly. [Now if only the one vendor we are having problems with would certify a 3.0 or better release of it's software] Rob.