mktime() failures under PCTS testing

Grant Sullivan grant at
Wed Mar 23 23:04:40 UTC 1994

In PCTS, "ambiguous" is referring to the time periods
	at, and 59:59 minutes after the start of daylight savings, where the
	   time given is as if there were no transition to daylight savings
        59:59 minutes before, and at the end of daylight savings, where the
	   time given is as if there were no transition from daylight savings
and tm_isdst = -1, assuming the difference between standard vs. daylight is
60:00 minutes.

I've run tests on SVR4v3 and HP-UX C.09.01 systems and found their mktime()
I think I prefer
but either mapping is acceptable to PCTS.

------- Forwarded Message

Return-Path: bww+ at
Received: from (, []) by (5.54/3.15) id <AA06638> for grant at; Wed, 23 Mar 94 14:51:15 EST
Received: by with BradMail(MH 6.8);
          Wed, 23 Mar 1994 14:51:06 -0500 (EST)
To: Grant Sullivan <grant at>
Cc: Arthur David Olson <ado at>
Subject: Re: mktime() failures under PCTS testing
In-Reply-To: Your message of Wed, 23 Mar 1994 13:37:01 -0500
Date: Wed, 23 Mar 1994 14:51:05 -0500 (EST)
Message-Id: <16001.764452265 at>
From: Bradley White <bww+ at>

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

The first and second senses of the word "ambiguous" should be distinguished.

The daylight->standard transition period does indeed include wall-clock times
that each correspond to two distinct time_t's.

However, the standard->daylight transition period renders wall-clock times
that simply do not exist.

And now my opinion:

I am all for mktime() failing for *all* non-existent times-of-day, but, given
that we do `isdst' correction, and map the non-existent times of ...

	02:MM:SS/DST-OFF  to  03:MM:SS/DST-ON
	02:MM:SS/DST-ON   to  01:MM:SS/DST-OFF

..., it seems that we should also map 02:MM:SS/DST-UNKNOWN to one of those.


PS: I won't mention that the test suite assumes too much about time_t's :-).

------- End of Forwarded Message

More information about the tz mailing list