mktime() failures under PCTS testing

Arthur David Olson ado
Wed Mar 23 00:03:37 UTC 1994


The ftpable-from-elsie version of the time zone code suffers the same fate
as related by grant at 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



More information about the tz mailing list