mktime() failures under PCTS testing

[Grant Sullivan]

>   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 at 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