delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1997/09/03/19:40:55

Date: Wed, 3 Sep 1997 19:40:39 -0400 (EDT)
Message-Id: <199709032340.TAA16866@delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: k3040e4 AT c210 DOT edvz DOT uni-linz DOT ac DOT at
CC: djgpp-workers AT delorie DOT com
In-reply-to: <199709032156.RAA01934@delorie.com> (message from Oberhumer
Markus on Wed, 3 Sep 1997 23:50:31 +0200 (METDST))
Subject: Re: 970831: mktime()

> > Why have a separate function?  Why not just fix mktime() and let
> > everyone benefit?
> 
> Because your last message says...
> 
> > mktime() "fix" for dates within a daylight savings time change (i.e.
> > two possible time_t results): I think that this *is* an error, and
> > mktime should return -1.  However, the original problem still exists:

Oh.

I still think it's an error to expect mktime() to do the "right thing"
during those intervals, because there is no "right thing".  However,
the results are thus *undefined* because there are two possible
correct answers (the spec says return -1 if there are no answers).

If we are going to "fix" this problem, we should fix mktime() itself,
so that all utilities benefit.  If we aren't going to fix it, then
we're still OK, but many things break.  If we fix it by adding a new
function, most programs will blindly use the standard mktime() and
won't benefit from our work.

At the moment, I'm inclined to fix mktime so that it quietly does
something useful in the undefined cases.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019