The ftpable-from-elsie version of the time zone code suffers the same fate as related by grant@osf; on our SunOS 4.1.1 system, after making this change to the sample code:
SCCS/s.try.c: 1.1 vs. 1.2 *** 1.1/try.c Tue Mar 22 18:45:08 1994 --- 1.2/try.c Tue Mar 22 18:45:08 1994 *************** *** 34,43 **** --- 34,53 ---- printf("mktime test: for this test, set TZ=dst0std,J057,J059\n"); printf("current value of TZ = %s\n", getenv("TZ"));
+ #if 0 if (setenv("TZ", TZ_value, 1) != 0) { printf("resetting TZ failed\n"); exit(1); } + #else + { + char buf[512]; + + (void) strcpy(buf, "TZ="); + (void) strcat(buf, TZ_value); + putenv(buf); + } + #endif printf("new value of TZ = %s\n", getenv("TZ"));
time_str.tm_year = TM_year - 1900;
...I get these results:
mktime test: PCTS/STD/LS/mktime 8.1.58_9 Assert 5.1.3 mktime test: for this test, set TZ=dst0std,J057,J059 current value of TZ = (null) new value of TZ = std0dst,J057,J059 time_str tm struct set to: year = 91, mon = 1, mday = 26, hour = 2, min = 0, sec = 0, wday = -1, yday = -1, isdst = -1 expected value from mktime = 667530000
mktime returned -1 (-unknown-) mktime() final time_str tm struct reset to: year = 91, mon = 1, mday = 26, hour = 2, min = 0, sec = 0, wday = -1, yday = -1, isdst = -1
Vintage time zone hands will recognize this as behavior that certain SunOS versions of the "cron" program clashed with. The time zone package is assuming that the "mktime" call is asking a question such as... If US DST rules are in effect and I'm in the Eastern US, when, on April 3, 1994, will a wall clock show 2:30 a.m. (irrespective of whether it is or isn't daylight saving time)? ...and the "-1" answer is the package's way of saying... There is no such time! If someone has the relevant wording from the current version of the relevant standard(s) on what to do here, I'd love to hear from you. --ado