Time conversion and second public review of draft proposed ANSI C

[Arthur David Olson]

I've yet to receive the draft proposed standard that's the subject of the
third public review period; I have, though, received "X3J11 Response ot Issues
Raised by Miscellaneous Public Comments (Not an official X3J11 document)."

Here's what the "Response" has to say on time conversion matters:

*	The range of seconds has been changed from "[0-59]" to "[0-60]"
	throughout, to allow for leap seconds.  Whether this is a good
	thing or not depends on what you think POSIX wants.

*	The Committee declined to change the phrase "time zone name" to
	"time zone name abbreviation".  Some vendors will be surprised when
	they learn that "strftime" is supposed to fill structures
	with pointers to strings such as "mountain standard time" (which
	is a time zone name) rather than to strings such as "MST" (which is
	a time zone name abbreviation).  Reading the Committee's response,
	I'm inclined to believe that I failed to clearly draw the distinction,
	and that a clearer explanation, along with a modified suggestion that
	the phrase be changed to "time zone name or abbreviation," might be
	more positively received.

*	The Committee declined to move the contents of footnote 109 into the
	Standard proper.  In my letter to the Committee, I said:

			Footnote 109 reads
				Thus, a positive or zero value for tm_isdst
				causes the mktime function initially to presume
				that Daylight Saving 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.
			The described behavior of mktime when tm_isdst is
			negative cannot be deduced from the Standard proper;
			given Section 4.12.1's words that "The value of
			tm_isdst is. . .negative if the information is not
			available," an implementer of mktime could reasonably
			say "No information about DST is available, so we
			won't try to account for it."

		Proposed Change
			Move the text of footnote 109 into the Standard proper,
			changing "Thus, a positive. . ." to "A positive. . ."

	The "Response" indicates that the Committee believes the behavior
	described in footnote 109 represents the only reasonable
	interpretation of the standard.  Looks as if the vendors will be able
	to take the easy way out (described above), and as if user's won't
	be able to rely on the "tm_isdst == -1" mechanism to get DST accounted
	for.
-- 
    "Only external identifiers and macro names described in the Standard
    as reserved shall be reserved" must go in.  This is non-negotiable.
	ado at ncifcrf.gov			ADO is a trademark of Ampex.