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
