Path: utzoo!attcan!uunet!ogicse!ucsd!ucbvax!PAN.SSEC.HONEYWELL.COM!thompson From: thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) Newsgroups: comp.sys.apollo Subject: re: Date and other wierd problems on an Apollo Dn4500 running Sr10.1 Message-ID: <9010260403.AA11351@pan.ssec.honeywell.com> Date: 26 Oct 90 04:03:50 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 40 > <> > We are experiencing wierd problem on a Dn4500 running SR10.1. > > Problem 1: The date is wrong. So I halt the machine and execute 'ex > calendar'. But, calendar thinks the date is already right (which in this > case is 10/24/90). So I boot the machine and check the date. Viola, it is > wrong again (this time it is: 10/25/90 00:48 or something like that). > > Also the Timezone is wrong. So as a last resort I set the date using the > /bin/date command. This seemed to have worked, but this is not the correct > way to set the date, right? The date you're seeing is probably right, if only you were in the right timezone! Since Apollos use the current time when they create an object on disk (they're not called UNIQUE identifiers as a joke), they don't want you changing the time just because daylight savings time starts (ends). Instead, they track everything in UTC (Greenwich Mean Time), and have a timezone offset. When you change the time zone, you change the effective LOCAL time that is displayed (although they still keep track of it in UTC). To change the time zone, use 'tz' (Example: "tz CST" will change us back from Central Daylight Time to Standard Time. We'll be doing it this Sunday, as a matter of fact. If for some reason you don't like using the time zone, you can use an offset instead, like "tz -10:00" to get Aleutian Standard Time (I think). YOu can use offsets with 30 minute increments as well (e.g. -4:30) if you have weird or funky timezones, and you can even NAME your time zone so that the machine calls it by your (up to 4 letter) name. What you can't get away with is changing the time to try and change the time-zone. (No help on problem #2 -- sorry) John Thompson (jt) Honeywell, SSEC Plymouth, MN 55441 thompson@pan.ssec.honeywell.com As ever, my opinions do not necessarily agree with Honeywell's or reality's. (Honeywell's do not necessarily agree with mine or reality's, either)