mktime() failures under PCTS testing

Paul Eggert eggert at twinsun.com
Fri Apr 1 23:00:33 UTC 1994


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 at sq.sq.com (Mark Brader)
Subject: Re: Can mktime return -1 for times in the spring-forward gap?
Message-ID: <1994Mar25.173447.2810 at sq.sq.com>
Summary: Yes, it's undefined behavior
Organization: SoftQuad Inc., Toronto, Canada
References: <Cn4tnp.DvM at twinsun.com> <2mr48c$duk at 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 at 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.



More information about the tz mailing list