mktime() failures under PCTS testing
grant at osf.org
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
I've run tests on SVR4v3 and HP-UX C.09.01 systems and found their mktime()
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, [188.8.131.52]) 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
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