mic@ut-emx.UUCP (Mic (... K[a-z]+) Kaczmarczik) (02/04/89)
How are the rest of you setting the local time zone on your cubes? When we started setting up a cube in our office yesterday, the clock was displaying Pacific time. After a fruitless search through the 0.8 user documentation and the on-line docs, I happened upon the time zone information database in /bootdisk/Admin/Private/conf/zoneinfo, copied the file ``US/Central'' into the file ``localtime'' and rebooted, and the time zone is right. Did miss an easier way of doing this? I sincerely hope so... Cheers, --mic-- -- Mic Kaczmarczik If you drink, don't drill. UT Austin Computation Center -- Matt Groening mic@emx.utexas.edu MIC@UTAIVC.BITNET
abe@mace.cc.purdue.edu (Vic Abell) (02/10/89)
In article <10176@ut-emx.UUCP>, mic@ut-emx.UUCP (Mic (... K[a-z]+) Kaczmarczik) writes: > How are the rest of you setting the local time zone on your cubes? /etc/zoneinfo/localtime need only be a link to the proper /etc/zoneinfo file - CST, EST, etc. You must also teach the kernel your time zone. Otherwise it will require a PST bias when you enter the time with date(1) and sendmail will continue to stamp your letters with PST. There is a new flag to date(1) that does this: "-t <minutesWest>". Add it to the first date(1) command in /etc/rc.boot - e. g., to establish EST date -t 300 >/dev/console
guy@auspex.UUCP (Guy Harris) (02/10/89)
>You must also teach the kernel your time zone. Otherwise it will require >a PST bias when you enter the time with date(1) and sendmail will continue >to stamp your letters with PST. That sounds like a botch. If a machine is running the Arthur Olson timezone code, as NeXT appears to be doing, programs using the standard "localtime", "ctime", etc. routines should be getting the time zone information from there, not from the kernel. Only binaries built with a library that doesn't use the Arthur Olson code should be fetching it from the kernel. Perhaps NeXT switched to the Olson code recently, and either 1) haven't updated their C library yet or 2) if the programs in question don't use a shared C library, haven't relinked them against the new library yet. Given that it's not FCS software (right?), this may be the case (the lack of "zic" or documentation for same, as indicated by the original poster, indicates that this might be the case). I would presume they'll fix it for FCS (and will provide the source to the time zone data bases, not just the compiled files, so that when your legislature changes the rules on you you're not stuck with the old rules - admittedly, since the files are supposed to be in a machine-independent format, you could, if necessary, update the databases on a Sun running 4.0 or later or a Mac II running A/UX - assuming Apple provides the source to the databases; I know Sun does - and zip the data files over to the NeXT).
guy@auspex.UUCP (Guy Harris) (02/10/89)
>...you could, if necessary, update the databases on a Sun running 4.0 >or later or a Mac II running A/UX... ...or just snarf the source to the "public domain timezone" stuff from "uunet", which contains the source to "zic" and the man page, as well as the source to the time zone files, and build "zic" and the data files on the NeXT.
abe@mace.cc.purdue.edu (Vic Abell) (02/11/89)
I neglected to mention that it may also be necessary to teach the kernel about daylight savings time when setting minutesWest. For those in Illinois, for example, date -t 360 -d 1 would be the correct invocation. Apparently sendmail is based on the standard, Berkeley distribution, which uses the ftime() and timezone() functions to derive the time zone. Other programs that use tzset() and localtime() will use the zone information of the TZ environment variable and/or the file /etc/zoneinfo/localtime. So, you must make sure that you have the minutesWest and DST values set properly in the kernel and that you have /etc/zoneinfo/localtime linked to the correct time zone file in /etc/zoneinfo.