.PN1 L....................................................................A .FO2 L.............................................R.......L..............A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA>@@ [[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ UNOTE 001‰ Page # of 1 L...............................................R.L..................A Ref: UNOTE 001~ From‰: Customer Services 4 Nov 1987~ Re‰ : CLOCK/TIMEZONE bug on PC/AT, Xenix 2.2.1 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA>@@ [[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ L.......T.......T.......T.......T.......T.......T.......T.......T....R PROBLEM@@ EEEEEEE A fault in SCO Xenix (2.1.1) libraries makes the UNIPLEX clock inaccurate if TIMEZONE is more than 9 hours from GMT (eg: TZ=ACT12ACT) WORK-AROUND@@ EEEEEEEEEEE Run with a TIMEZONE within 9 hours of GMT Example H....L..T.......T.......T.......T.......T.......T.......T.......T....R 1. Compile the following program as "ctime" (eg: cc -o ctime ctime.c): .JN #include @@ AAAAAAAAAAAAAAAAA main ()@@ AAAAAAA {@@ A longtim;@@ AAAAAAAA time(&tim);@@ AAAAAAAAAAA puts(ctime(&tim));@@ AAAAAAAAAAAAAAAAAA }@@ A .JY 2. Run the following commands (shown bold, responses normal):-@@ AAAA .JN $ TZ=xyz0xyz; export TX@@ AAAAAAAAAAAAAAAAAAAAAAA $ date@@ AAAAAA Wed Oct 28 13:21:02 xyz 1987 $ ctime@@ AAAAAAA Wed Oct 28 13:21:14 1987 $ TZ=xyz12xyz@@ AAAAAAAAAAAAA $ date@@ AAAAAA Wed Oct 28 01:22:01 xyz 1987 $ ctime@@ AAAAAAA Wed Oct 28 19:34:42 1987 .JY 3. Note the invalid output from the second ctime invocation (with a@@ AAAAA 12 hour GMT shift) - both the hours and the minutes are messed up! L.......T.......T.......T.......T.......T.......T.......T.......T....R Update (October 1989)@@ CCCCCCCCCCCCCCCCCCCCC It appears that this bug is fixed in Xenix 2.2.3.