Time conversion and second public review of draft proposed ANSI C
Arthur David Olson
Wed Jun 1 16:32:20 UTC 1988
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
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."
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
"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.
More information about the tz