Date: Fri, 17 Dec 1999 00:00:03 -0800 (PST) From: Andre Albsmeier <andre.albsmeier@mchp.siemens.de> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/15520: mktime() fails under certain conditions Message-ID: <199912170800.AAA09093@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/15520; it has been noted by GNATS.
From: Andre Albsmeier <andre.albsmeier@mchp.siemens.de>
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: Andre Albsmeier <andre.albsmeier@mchp.siemens.de>,
FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/15520: mktime() fails under certain conditions
Date: Fri, 17 Dec 1999 08:57:38 +0100
On Thu, 16-Dec-1999 at 21:52:17 +0100, Poul-Henning Kamp wrote:
> In message <19991216213647.A34480@internal>, Andre Albsmeier writes:
> >On Thu, 16-Dec-1999 at 21:24:41 +0100, Poul-Henning Kamp wrote:
> >> In message <199912162016.VAA97593@internal>, Andre Albsmeier writes:
> >>
> >> There is no 02:00:00 that night. If they test for that, they're
> >> crazy.
> >
> >Yes, the time does not exist. However, I only wonder it our
> >behaviour of returning an error is correct in this case. I don't
> >trust the GNU/Linux guys as much as I trust FreeBSD :-) but there
> >might be a reason they are testing it.
> >
> >I was already asked in private email if the mktime() should
> >succeed according to POSIX.1... Does somebody know anything
> >about that?
>
> Well, Hum. It seems to say that the fields are not constrained
> to their normal domains:
>
> The original values of the tm_wday and tm_yday components
> of the structure are ignored, and the original values of
> the other components are not restricted to the ranges
> described in the <time.h> entry.
>
> It does not describe what should happen if I ask it to make a time
> out of 25:100:100, but I guess most of us can agree what it should
> do.
>
> The trouble with passing it 02:00:00 or for that matter 02:59:00
> on the "spring forward" night, is that the time doesn't exist in
> the first place: Ie, does 02:10:00 represent
>
> 01:59:59 + 10:59 = 03:10:00
> or
> 03:00:00 - 50:00 = 01:10:00
>
> Since no sane argument either way really holds water, I think
> returning an error is correct.
As I wrote initally, the problem arises when configure tries to
determine if mktime() works. I have now looked what happens in this
case: The program replaces mktime with its own call. For the record,
here is the interesting part (mktime.c, around line 277):
if (t == t1 && t != t2
&& (isdst < 0 || tm.tm_isdst < 0
|| (isdst != 0) != (tm.tm_isdst != 0)))
/* We can't possibly find a match, as we are oscillating
between two values. The requested time probably falls
within a spring-forward gap of size DT. Follow the common
practice in this case, which is to return a time that is DT
away from the requested time, preferring a time whose
tm_isdst differs from the requested value. In practice,
this is more useful than returning -1. */
break;
else if (--remaining_probes == 0)
return -1;
-Andre
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912170800.AAA09093>