mechjgh@tness1.UUCP (8753) (05/06/87)
OK, I give up... where is the EST time zone coming from ? Is it because DEC is in Maynard, Massachusettes ? All incoming mail from remote systems bears a EST time stamp (instead of CST that I'm in). Do I have to change tzname in ctime.c and recompile everything? Or is there some easy magic. System: VAX 11/785 S5R2 w/ HoneyDanBer uucp
mechjgh@tness1.UUCP (8753) (05/09/87)
In article <187@tness1.UUCP> mechjgh@tness1.UUCP (Greg Hackney) writes: >> >> All incoming mail from remote systems bears a >> EST time stamp (instead of CST that I'm in). >> Do I have to change tzname in ctime.c and recompile everything? >> Or is there some easy magic. >> System: VAX 11/785 S5R2 w/ HoneyDanBer uucp In article <8705080829.aa06986@SEM.BRL.ARPA> rachiele@nadc.arpa (Jim) replys: > On system V machines, to get the time zone to come up right all you have > to do is properly set the TZ parameter. The file /etc/profile is executed. I apologize, I should have been more specific..... The mailer programs ARE converting the time into the correct time zone for the user. It's the time stamp that uucp generates that is in question (uucico does not execute /etc/profile at login), for example: From uucp Wed Apr 22 14:18 EST 1987 >From mechmah Wed Apr 22 13:13 CST 1987 remote from tness3 This is really a stupid concern: Some of the users (upper managers no less) were complaining that their mail was arriving an hour late. They were looking at the 1st line that the *mail* program generates, which is the EST date. They haven't learned to use the sophisticated mailers yet that strips this. My boss asked me to fix it to CST, and the only way I see to do it is to recompile all programs that use tzname in ctime.c (which is set at factory to EST). I am looking for an easy (but standard) way out. -- Greg Hackney UUCP: ihnp4!mechjgh!tness1 Hummingbirds never remember the words to songs.
philip@axis.UUCP (05/10/87)
In article <187@tness1.UUCP>, mechjgh@tness1.UUCP writes: > > OK, I give up... where is the EST time zone coming from ? > Is it because DEC is in Maynard, Massachusettes ? No, nothing at all to do with DEC (?!). Its because Bell Labs is in New Jersey. Because of the inconsistency in setting TZ in all previous versions of UNIX, some bright spark hard-wired EST and an offset of 5 hours into the time routines in the standard C library. Thus, if you don't set TZ, it uses the default value (which I suggest should be GMT), which is EST. > All incoming mail from remote systems bears a > EST time stamp (instead of CST that I'm in). Your uucp login runs /usr/lib/uucp/uucico directly - without a shell, so, no reading of /etc/profile etc to set up a TZ. So, it has the default of EST. > Do I have to change tzname in ctime.c and recompile everything? > Or is there some easy magic. There are three solutions: 1) Change ctime.c and re-compile (YUK !) - this will make the system work for you, but is just perpetuating the stupidity. This also assumes access to the sources. 2) Easy, but slightly ugly: Don't run uucico directly. Run a shell instead, and put a .profile containing something like: TZ=CST?CST # or whatever for your TZ export TZ exec /usr/lib/uucp/uucico exit The exit is there in case of problems execing uucico, it prevents people getting a shell via a uucp login. This solution requires no source access. 3) The best solution, if you have access to the sources, is to hack init to accept another keyword, rather than running a command, it will take all the variable defines on the line and add them to the environment of ALL sub processes - and since init is the ancestor of all processes, everyone gets these variables. For example: ev::environ:TZ=MET-1MET This sets TZ correctly for all processes on our machine. You can throw away all those stupid TIMEZONE files etc. Philip
sverre@fesk.UUCP (Sverre Froyen) (05/12/87)
in article <229@axis.fr>, philip@axis.UUCP says: > 1) Change ctime.c and re-compile (YUK !) > This also assumes access to the sources. For those of us without source, is there a (simple) way to apply adb to the kernel to affect the timezone change (like changing some variable). -- Sverre Froyen UUCP: boulder!fesk!sverre, sunpeaks!seri!fesk!sverre ARPA: froyen@nmfecc.arpa BITNET: froyen@csugold.bitnet
guy%gorodish@Sun.COM (Guy Harris) (05/12/87)
> For those of us without source, is there a (simple) way to apply adb > to the kernel to affect the timezone change (like changing some variable). Since the discussion was about System V, the answer is "no" unless a system call was added to the System V in question to return time zone information. The releases from AT&T don't have this.
philip@axis.UUCP (05/18/87)
In article <138@fesk.UUCP>, sverre@fesk.UUCP writes: > in article <229@axis.fr>, philip@axis.UUCP says: > > 1) Change ctime.c and re-compile (YUK !) > > This also assumes access to the sources. > > For those of us without source, is there a (simple) way to apply adb > to the kernel to affect the timezone change (like changing some variable). Unfortunately, its not that simple. All of the time conversion routines are in the C library. Unless you have the latest version of S5.3 with its sharable libraries, the code is compiled into EVERY program which makes use of them. So, your answer is - yes, you could do it with adb, assuming that the programs are not striped, and you are happy to hack ALL of your progs. Philip