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.
The relevant standard (i.e. the C standard) is obscure in this area. The closest that it comes to addressing the problem is the ANSI C Rationale, section 4.12.2.3 (ANSI X3.159-1989 page 109), which says:
I also found the POSIX.1 standard vague, since it largely refers to the ISO/IEC 9899 C standard. I found the X/Open XPG4 standard more helpful. XPG4 (CAE Specification: System Interfaces and Headers, Issue 4), mktime(), pg. 275, says: A positive or zero value for tm_isdst causes the mktime() function to presume initially that Daylight Savings Time, respectively, is or is not in effect for the specified time. A negative value for ^^^^^^^^^^^^^^^^^^^^ tm_isdst causes the mktime() function to attempt to determine ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ whether Daylight Saving Time is in effect for the specified time. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Local timezone information is set as though mktime() called tzset(). Upon successfull completion, the values of the tm_wday and tm_yday components of the structure, and the other components are set to ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ represent the specified time since the Epoch, but with their values ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ forced to the ranges indicated in the <time.h> entry; the final value of tm_mday is not set until tm_mon and tm_year are determined. RETURN VALUE The mktime() function returns the specified time since the Epoch encoded as a value of type time_t. If the time since the Epoch cannot be represented, the funtion returns the value (time_t)-1. (^^^'s added by me) Therefore, when mktime() is called with tm_isdst = -1, the caller is saying in effect "I don't know if this date/time is Standard or Daylight Saving. Tell me what it is. Adjust the date/time, if necessary." XPG4 mktime() provides an example program with tm_isdst set to -1, which example asks the question "What day of the week is July 4, 2001?", but XPG4, unfortunately, does not tell you the answer you should get.
From: eggert@twinsun.com (Paul Eggert)
Of course, if PCTS is pickier than the standard requires, we don't have to change mktime to agree with PCTS. But it might be more consistent to do so, ...
The NIST-PCTS:151-2, Version 1.4, 12/3/93, test suite, when the struct tm is set to a date/time that falls within the ambiguous transition from standard to daylight time, and tm_isdst = -1, allows the implementation to return either the "old" standard time, or the new daylight time, but rejects a return value of -1. So it would appear in this case that NIST-PCTS favors the XPG4 notion of mktime() attempting to determine the time mode, rather than mktime() rejecting the tm_isdst = -1 input. NIST-PCTS does not not care which of the two Epoch times are returned, so is less picky. mktime() is failing only those PCTS tests which test "ambiguous" transitions from standard to daylight time. mktime() passes all the tests for "ambiguous" transitions from daylight to standard time, however. Grant Sullivan