marmen@bwdla31.bnr.ca (Rob Marmen 1532773) (04/04/91)
A week ago, I posted an article asking for help with the TZ command. I recieved a couple of usefull answers, but my problem persists. The following code shows what I mean: % tz <----- This is the current timezone Timezone: EST Delta from UTC: -5:00 % /bin/date <---- Output of the BSD4.3 date command Wed Apr 3 15:45:53 EST 1991 % tz edt <---- Change the timezone % tz Timezone: EDT Delta from UTC: -4:00 % /bin/date <---- Check the date, and it's wrong Wed Apr 3 15:46:06 EST 1991 % tz <---- Verify the timezone Timezone: EDT Delta from UTC: -4:00 However, the date command under /com will work correctly. Here, cdate is a copy of /com/date % date Wed Apr 3 15:52:38 EST 1991 % cdate Wednesday, April 3, 1991 3:52:41 pm (EST) % tz edt % date Wed Apr 3 15:52:50 EST 1991 % cdate Wednesday, April 3, 1991 4:52:53 pm (EDT) Unfortunately, we do not distribute the /com directory with the o/s. We are running bsd4.3. Does anyone have any ideas on how to fix this? Or, does the bsd4.3 date command simply look at a different clock? Thanks for the help, rob.... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Robert Marmen marmen@bnr.ca OR | | Bell Northern Research marmen%bnr.ca@cunyvm.cuny.edu | | (613) 763-8244 My opinions are my own, not BNRs |
thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) (04/04/91)
> A week ago, I posted an article asking for help with the TZ command. > I recieved a couple of usefull answers, but my problem persists. > > % tz edt <---- Change the timezone > % /bin/date <---- Check the date, and it's wrong > Wed Apr 3 15:46:06 EST 1991 > % tz <---- Verify the timezone > Timezone: EDT > Delta from UTC: -4:00 > > However, the date command under /com will work correctly. > > Does anyone have any ideas on how to fix this? Or, does the bsd4.3 date > command simply look at a different clock? This same problem was discussed last year about this time (funny how that works). :-) As I understand it from the previous discussion, the problem is that Unix decides to be 'intelligent', and try to figure out Daylight Savings Time for you. Both Aegis and Unix use the same clock -- it's kept in UTC, though. Aegis applies the timezone offset to get the local time, and will never second-guess you. Of course, this means that Aegis will not automatically change over, either. You need either a cron script or you run around early Sunday AM changing the 'tz' everywhere. Unix, apparently, tries to figure out when daylight savings time goes into effect, and changes over at that point. The tz command does nothing for it except to get the actual zone (not the particular offset for daylight/standard time). This might be fixed when you reboot (I can't remember for sure), but it definitely isn't dynamic like Aegis is. (Yet another example of the inate superiority of Aegis over Unix! :-) -- jt -- John Thompson Honeywell, SSEC Plymouth, MN 55441 thompson@pan.ssec.honeywell.com Me? Represent Honeywell? You've GOT to be kidding!!!
hanche@imf.unit.no (Harald Hanche-Olsen) (04/06/91)
In article <9104032251.AA19047@pan.ssec.honeywell.com> thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) writes:
Unix, apparently, tries to figure
out when daylight savings time goes into effect, and changes over at that point.
The tz command does nothing for it except to get the actual zone (not the
particular offset for daylight/standard time).
Hmmm, looks like someone has decided that Unix shouldn't try to do
this second-guessing if you're outside the US, which presumably
explains why we don't see this problem at all. Actually not all
unixes are not this smart: Some DECstation near here decided to
change to DST a week early (Europe changed a week later than the US
this year, I think).
- Harald Hanche-Olsen <hanche@imf.unit.no>
Division of Mathematical Sciences
The Norwegian Institute of Technology
N-7034 Trondheim, NORWAYkumorek@apollo.HP.COM (James Kumorek) (04/08/91)
In article <1991Apr3.205041.1361@bwdls61.bnr.ca>, marmen@bwdla31.bnr.ca (Rob Marmen 1532773) writes: |> A week ago, I posted an article asking for help with the TZ command. |> I recieved a couple of usefull answers, but my problem persists. |> The following code shows what I mean: |> |> % tz <----- This is the current timezone |> Timezone: EST |> Delta from UTC: -5:00 |> |> % /bin/date <---- Output of the BSD4.3 date command |> Wed Apr 3 15:45:53 EST 1991 |> % tz edt <---- Change the timezone |> % tz |> Timezone: EDT |> Delta from UTC: -4:00 |> |> % /bin/date <---- Check the date, and it's wrong Reboot your node after changing the timezone with the tz command. Jim Kumorek Apollo Computer, Inc. - A subsidiary of Hewlett Packard kumorek@apollo.hp.com
rfh3273@galileo.rtn.ca.boeing.com (Dick Harrigill) (04/10/91)
John Thompson writed (wrote, typed, said, pointed out, or whatever): >You need either a cron script or you run around early Sundy AM >changing the 'tz' everywhere. For everyone's edification, here is one way to globally change time zones. I believe this wouldn't work with older versions of the OS, but it does work with 10.2 & 10.3. I have run this script after the last 3-4 time changes (on an Apollo only ring network) with no other action needed: -------------------------------------------------------------------- #!/com/sh eon command := '/com/tz pdt' for node in ^"catf node_list" by line crp "^command" -on //^node -me -cp endfor ---------------------------------------------------------------------- file "node_list" simply is a list of all nodes by name -- Dick Harrigill, an independent voice from: Boeing Commercial Airplanes M/S 9R-49 PO BOX 3707 Renton Avionics/Flight Systems Seattle, WA 91824 Computing Support (206) 393-9539 rfh3273@galileo.rtn.ca.boeing.com
fleureck@imec.be (Marc Fleureck) (04/11/91)
In article <1991Apr3.205041.1361@bwdls61.bnr.ca>, marmen@bwdla31.bnr.ca (Rob Marmen 1532773) writes: > A week ago, I posted an article asking for help with the TZ command. > I recieved a couple of usefull answers, but my problem persists. > > However, the date command under /com will work correctly. > > ... We are running bsd4.3. > > Thanks for the help, > > rob.... I experienced the same kind of problem with SR10.2. After using /com/tz ... the /com/date was ok, but /bin/date did not change. Also, when I used 'rlogin' or 'rsh' to the machine itself, the /bin/date had changed ! ( as in 'rsh <machine> /bin/date' ). The only thing that helped was to reboot the machine. That ment I had to reboot over 60 apollos ! This is only true for SR10.2 and lower versions of DOmain/OS. Fortunately, SR10.3 does not have this problem, at least on the Series 400 line. ( I was not able to test this out on the DNxxx ) Marc Fleureck System Administrator Unix IMEC vzw Belgium E-mail: fleureck@imec.be
chen@digital.sps.mot.com (Jinfu Chen) (04/13/91)
>#!/com/sh >eon >command := '/com/tz pdt' > >for node in ^"catf node_list" by line > crp "^command" -on //^node -me -cp >endfor >---------------------------------------------------------------------- > >file "node_list" simply is a list of all nodes by name Or you can let lcnode to figure out al the node names: for node in ^"/etc/lcnode -r -b" by line crp -cp "^command" -on ^node -me endfor or in Bourne shell syntax: #!/bin/sh command='/com/tz pdt' for node in `/etc/lcnode -r -b`; do /com/crp -on ${node} -me -cp ${command} done
dennis@nosc.mil (Dennis Cottel) (04/15/91)
chen@digital.sps.mot.com (Jinfu Chen) writes: > >for node in ^"catf node_list" by line > >where file "node_list" simply is a list of all nodes by name > Or you can let lcnode figure out all the node names: > for node in ^"/etc/lcnode -r -b" by line Unfortunately, HP/Apollo has not seen fit to make this work with multiple rings in an Apollo internet. Dennis Cottel, dennis@NOSC.MIL, (619) 553-1645 Naval Ocean Systems Center, San Diego, CA 92152
rees@dabo.citi.umich.edu (Jim Rees) (04/16/91)
In article <dennis.671728212@woodstock>, dennis@nosc.mil (Dennis Cottel) writes: > Or you can let lcnode figure out all the node names: > for node in ^"/etc/lcnode -r -b" by line Unfortunately, HP/Apollo has not seen fit to make this work with multiple rings in an Apollo internet. It occurs to me that there must be some way to get ns_helper to tell you the names of all the nodes in your Domain internet, but I can't figure it out right now, and the documentation is of course no help at all (neither the lcnode or ctnode man pages even mention ns_helper, and there is no man page for ns_helper). Anyone know how to do this? For a short list, I use "ls //*" but that won't get them all, obviously, since it doesn't talk to ns_helper.
rtb@cernapo.cern.ch (Rainer Tobbicke) (04/16/91)
Related to this: has anybody got an idea on how to introduce the TZ environment variable into every process and it's children? In any Unix environment it does not make sense to mess around with /com/tz every 6 months, since TZ can handle all this quite well a la POSIX. Only: it assumes that the TZ environment variable is always present. I wouldn't mind rebooting once (!) for this. I tried setting it in /etc/rc, where at least all inetd children seem to get it. But things started by /etc/init e.g. from /etc/ttys (like the DM) do not. /etc/TIMEZONE helps for /bin/sh users, but not /bin/csh. Also, I feel that when I 'crp -me' to a node TZ should be set which does not seem to be the case. 'man login' claims that TZ will be initialised, but if that is true then it's initialised to "" ! Some help file claims TZ is initialised from what's recorded on the disk. Rubbish! (at least under 10.3) Any ideas? -- Rainer Toebbicke European Organisation for Nuclear Research (CERN) Geneva, Switzerland rtb@cernapo.cern.ch, rtb@cernvm.cern.ch
vince@bcsaic.UUCP (Vince Skahan) (04/16/91)
In article <dennis.671728212@woodstock> dennis@nosc.mil (Dennis Cottel) writes: >chen@digital.sps.mot.com (Jinfu Chen) writes: > >> >for node in ^"catf node_list" by line >> >where file "node_list" simply is a list of all nodes by name > >> Or you can let lcnode figure out all the node names: >> for node in ^"/etc/lcnode -r -b" by line > >Unfortunately, HP/Apollo has not seen fit to make this work with multiple >rings in an Apollo internet. > lots of things don't work over multiple rings in an Apollo internet like most of the Domain diagnostics for example. we told Hpollo "look...either you support Domain over ethernet or you don't...please don't half-ass us and claim full functionality when you clearly know it's not there and you have no plans of getting there". it's 3 years later and they're still claiming stuff that's not true. I won't mention the particular security holes I put APRs in on starting at SR9.5 that STILL aren't closed up yet...their networking is so good, even THEY can't (or won't) make it at least a little secure. -- Vince Skahan vince@atc.boeing.com ...uw-beaver!bcsaic!vince (what is there in the construction of mobile homes that seems to attract tornadoes ??? )
rfh3273@galileo.rtn.ca.boeing.com (Dick Harrigill) (04/18/91)
In article <50ef33dd.3593b@digital.sps.mot.com> chen@digital.sps.mot.com (Jinfu Chen) writes: >>#!/com/sh >>eon >>command := '/com/tz pdt' >>for node in ^"catf node_list" by line >> crp "^command" -on //^node -me -cp >>endfor >>---------------------------------------------------------------------- >>file "node_list" simply is a list of all nodes by name >Or you can let lcnode to figure out al the node names: >for node in ^"/etc/lcnode -r -b" by line > crp -cp "^command" -on ^node -me >endfor Yes. However, the reason I was using a list (rather that letting lcnode figure out who's there) is in case a node is down. A list will give an error message and I know to return to it later. In general, and for this reason, I rarely rely on lcnode to perform such tasks. -- Dick Harrigill, an independent voice from: Boeing Commercial Airplanes M/S 9R-49 PO BOX 3707 Renton Avionics/Flight Systems Seattle, WA 91824 Computing Support (206) 393-9539 rfh3273@galileo.rtn.ca.boeing.com
chen@digital.sps.mot.com (Jinfu Chen) (04/18/91)
In article <rtb.671798464@cernapo.cern.ch> rtb@cernapo.cern.ch (Rainer Tobbicke) writes: >Related to this: has anybody got an idea on how to introduce >the TZ environment variable into every process and it's >children? In any Unix environment it does not make sense to >mess around with /com/tz every 6 months, since TZ can handle all this quite >well a la POSIX. I believe the TZ (and TZNAME) environment variables are set automatically in the Unix environment, at least in US. It's the automatic setting feature that really bugs us who live Arizona (we don't have summer saving time). What I ended up doing (learn from suggestion in comp.sys.apollo long time ago) is to add the TZ and TZNAME in /etc/rc and /sys/node_data/startup.* files so we always have the right timezone setting. >Only: it assumes that the TZ environment variable is always >present. I wouldn't mind rebooting once (!) for this. >I tried setting it in /etc/rc, where at least all inetd >children seem to get it. But things started by /etc/init e.g. >from /etc/ttys (like the DM) do not. /etc/TIMEZONE helps for Try setting TZ in /sys/node_data/startup.*, such as in our /sys/node-data/startup.1280color file: # to defeat automatic summer saving time ENV TZ MST7 ENV TZNAME MST