mktime() failures under PCTS testing

[Grant Sullivan]

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()
maps
	02:MM:SS/DST-UNKNOWN	to	 01:MM:SS/DST-OFF
I think I prefer
	02:MM:SS/DST-UNKNOWN	to	 03:MM:SS/DST-ON
but either mapping is acceptable to PCTS.

------- Forwarded Message

Return-Path: bww+ at transarc.com
Received: from sparc51.transarc.com (sparc51.transarc.com, [192.55.207.51]) by transarc.com (5.54/3.15) id <AA06638> for grant at osf.org; Wed, 23 Mar 94 14:51:15 EST
Received: by sparc51.transarc.com with BradMail(MH 6.8);
          Wed, 23 Mar 1994 14:51:06 -0500 (EST)
To: Grant Sullivan <grant at osf.org>
Cc: Arthur David Olson <ado at elsie.nci.nih.gov>
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 sparc51.transarc.com>
From: Bradley White <bww+ at transarc.com>

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

Bradley

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

------- End of Forwarded Message