Mark Brader, who I believe is well connected with the C standardization process, wrote a news article about the mktime problem in which he indicated that he thought that mktime could yield -1 in the spring-forward gap (i.e. that this particular PCTS case is incorrect). I'll enclose a copy of the article at the end of this message. (It responds to another article that I don't have a copy of.) This is probably the best we can do until I get an official response to the C Standard defect report that I filed earlier this week. ----- Newsgroups: comp.std.c From: msb@sq.sq.com (Mark Brader) Subject: Re: Can mktime return -1 for times in the spring-forward gap? Message-ID: <1994Mar25.173447.2810@sq.sq.com> Summary: Yes, it's undefined behavior Organization: SoftQuad Inc., Toronto, Canada References: <Cn4tnp.DvM@twinsun.com> <2mr48c$duk@usenet.pa.dec.com> Date: Fri, 25 Mar 94 17:34:47 GMT The original question was about mktime() with the tm_isdst member negative, and times in the "spring-forward gap", i.e. the transition to Daylight Saving Time.

I think the standard contradicts itself. The relevant fields are not restricted to the usual ranges, yet if the calendar time cannot be represented then mktime returns -1. I think that your example requires a return of -1, and an example with tm_hour being 27 is a calendar time that cannot be represented so it requires a return of -1, even though mktime has to force the fields into the usual ranges.

I think that this is a strained interpretation, and that if a ruling was requested, the response would be that the standard is clear enough as it is. The intent of saying that "the original values ... are not restricted to the ranges indicated above" obviously was to allow alternative specifications for a calendar time, so that 27:00 UTC on October 15, 1982, would signify the same as 03:00 UTC on October 16, 1982; and I don't think there is any other reasonable way to read the actual text.

...

The Rationale (section 4.12.2.3) clearly allows mktime to yield -1 in the ``fall-backward fold'' [i.e. the opposite transition]...

The rationale conflicts with the standard, and the standard has priority. If the tm_isdst field is -1, then a time in the "fall-backward fold" is a calendar time that can be represented in two ways, so it can be represented, so the return value cannot be -1 ...

The Rationale for 4.12.2.3 does not specify what kind of behavior is involved here, but seems to mean that it is unspecified; perhaps that is what was intended. On reading 4.12.2.3/7.12.2.3 in the actual standard, though, I think the behavior is undefined. What it specifies is only that the broken-down time is converted to a calendar time value. For times in the gap and the fold, no well-defined conversion exists. Therefore, as I see it, the general exclusions in 1.6/3.16 and/or 4.1.6/7.1.7 apply, and the behavior is undefined. (And I think that's an unwise choice; I'd rather that it either be unspecified, or implementation-defined, or that -1 be returned.)

Perhaps now is the calendar time for a few more defect reports.

Chuckle. I'd say so.

Every technical corrigendum is met by an equally troublesome new defect report.

But then again... -- Mark Brader, msb@sq.com | "You keep using that word. I do not think it means SoftQuad Inc., Toronto | what you think it means." -- The Princess Bride This article is in the public domain.