bug in NIST-PCTS test suite (when testing mktime)
eggert at twinsun.com
Tue Oct 29 23:09:27 UTC 1996
Date: Tue, 29 Oct 1996 14:36:25 -0700
From: "Todd C. Miller" <Todd.Miller at cs.colorado.edu>
Here is the exact test the POSIX test suite is using that fails.
struct tm tm;
tm.tm_isdst = -1;
tm.tm_sec = 0;
tm.tm_min = 0;
tm.tm_hour = 2;
tm.tm_mday = 26;
tm.tm_mon = 1;
tm.tm_year = 91;
tm.tm_wday = 2;
tm.tm_yday = -1;
t = mktime(&tm);
printf("Actual: %ld\n", (long)t);
That test (which appears to be taken from
NIST-PCTS/STD/LS/src/mktime/8.1.58_09.c) is attempting to apply
`mktime' to 1991-02-26 02:00:00 with isdst set to -1. When
TZ='dst0std,J057,J059', the requested local time never exists (the
clock jumps from 01:59:59 to 03:00:00), so the C Standard allows
mktime to return -1 in this case.
The POSIX test suite is therefore erroneous here. I'll CC: this
message to 151-2 at sst.ncsl.nist.gov, as I understand it's the right
address to report bugs in the POSIX test suite.
(If tzcode were modified to work around the bug in the Posix test
suite, it'd still conform to Posix; this might take less time than
fixing the bug in the test suite. This would be reminiscent of the
optional PCTS-bug workaround that's already in tzcode.)
I asked the C Standard committee about a very similar test case a
while ago, and they gave an official response that a -1 return is OK.
The rest of this message contains a copy of the request and response,
taken from the official record of C Standard interpretations at
<URL:ftp://ftp.dmk.com/DMK/sc22wg14/rr/defec130.txt.gz>. Posix just
copies the C Standard in this area, so a -1 return conforms to Posix too.
Defect Report #136
*Submission Date*: 31 Mar 94
*Submittor*: Project Editor (P.J. Plauger)
*Source*: Paul Eggert
Suppose I run the following program in a US environment, where the
clocks will jump forward from 01:59:59 to 03:00:00 on April 3, 1994.
This program attempts to invoke `mktime' on a `struct tm'
that represents 02:30:00 on that date. Does the C Standard let `mktime'
return -1 in this case?
struct tm t;
/* 1994-04-03 02:30:00 */
t.tm_year = 1994 - 1900; t.tm_mon = 3; t.tm_mday = 3;
t.tm_hour = 2; t.tm_min = 30; t.tm_sec = 0;
t.tm_isdst = -1; /* i.e. unknown */
r = mktime(&t);
if (r == -1)
The ANSI C Rationale (corresponding to subclause 220.127.116.11) clearly
lets `mktime' yield -1 in the ``fall-backward fold''
that will occur when the clock is turned back from 01:59:59 to 01:00:00
on October 30, 1994. The question is whether `mktime' is also
allowed to yield -1 in the ``spring-forward gap'' when the
clock is advanced from 01:59:59 to 03:00:00.
This question arose when Arthur David Olson's popular ``tz''
time zone software was tested using NIST-PCTS:151-2, Version 1.4,
(1993-12-03) a test suite put out by the National Institute of Standards
and Technology that attempts to test C and Posix conformance. The
PCTS package insists that in the above case, `mktime' must yield
a `time_t' corresponding to either 01:30:00 or 03:30:00; i.e.
PCTS rejects Olson's `mktime', which yields -1.
This test case differs in an important way from the common practical
use of `mktime' to ``add 1'' to the output of `localtime'
or `gmtime', since those functions normally set `tm_isdst'
to a nonnegative value, whereas `tm_isdst' is -1 in the case
I suggest that the Committee issue a clarification which makes it
clear that `mktime' can yield -1 in the spring-forward gap
when `tm_isdst' is -1.
The Standard does not specify the behavior precisely enough to preclude
`mktime' from returning a value of `(time_t)-1' and leaving
the `tm_isdst' member set to -1 in such situations.
More information about the tz