The following reply was made to PR standards/24898; it has been noted by GNATS.

From: "Greg A. Woods" <woods@weird.com>
To: jmc@netbsd.org
Cc: kleink@netbsd.org,
	NetBSD GNATS submissions and followups <gnats-bugs@netbsd.org>,
	gnats-admin@netbsd.org, wolfgang@wsrcc.com
Subject: Re: standards/24898: emacs thinks mktime is broken
Date: Tue, 1 Feb 2005 17:36:51 -0500 (EST)

 [ On Monday, January 31, 2005 at 05:45:16 (+0000), jmc@netbsd.org wrote: ]
 > Subject: Re: standards/24898
 >
 > Synopsis: emacs thinks mktime is broken
 > 
 > State-Changed-From-To: open->closed
 > State-Changed-By: jmc@netbsd.org
 > State-Changed-When: Mon, 31 Jan 2005 05:45:16 +0000
 > State-Changed-Why:
 > As Klaus points out, this behavior that emacs is checking for is standards
 > compliant and emacs is simply being more pedantic than the standard requires.
 
 But NetBSD's mktime() _is_ broken for certain requests, and emacs isn't
 just being pedantic -- it relies on the "fixed" behaviour and may fail
 if the system mktime() exhibits the bug it test for.
 
 I don't know about minimal standards compliance since the committees
 have political pressure to avoid changes that they might deem
 unimportant, but the problem identified in the check is very real and
 for some applications like emacs the problem can be quite important
 since they cannot predict which timezones might trigger an inappropriate
 "failure".  The best they can do in face of this bug is to try to avoid
 ever expressing any times in DST (or any other offset scheme that might
 create "gaps").
 
 I.e. emacs (or any other application) cannot notice that a gap exists
 and avoid it -- it's simply impossible to do (without first delving into
 the guts of the specified timezone's zoneinfo file).  These gap times
 _ARE_ used in practice any time any time offset is calculated that might
 run "into" the gap.  I.e. Wolfgang's rationale w.r.t. these times "not
 existing" in the earlier discussion is simply wrong.
 
 For example, what time is it 45 minutes from "now" if "now" is 15
 minutes before a gap?  Mktime() just returns an error because it refuses
 to convert a time from within the gap, but there's no standard
 application level API which the application can use to determine the
 length of the impending gap (or, IIRC, even when the gap starts).  Some
 Emacs features can end up using time offsets very regularly (alarm and
 appointment applications, for example).  Failing to use the emacs
 mktime() implementation on *BSD machines will cause these applications
 to fail (during one time period once per year in any locale which uses
 anything like daylight savings time).
 
 I'm also reasonably certain that there are no possible locale-specific
 reasons for prefering libc mktime() vs. the variant supplied in the
 emacs sources.  The process of converting a "struct tm" to "time_t" is
 simply not affected by any locale-specific attributes -- and the emacs
 implementation uses the libc localtime() to make sure any system
 specific timezone offset handling is done consistently with othe system
 tools.
 
 Note that I started a discussion about this a long time ago:
 
 	http://mail-index.netbsd.org/tech-userlevel/2002/10/05/0000.html
 
 but it seemed quite a few people fell into the same trap Woflgang has
 done back then as well.
 
 > (most likely so it has the easy excuse for using it's own internal routines).
 
 Well at least the one it provides isn't broken.
 
 
 As for the best place to discuss this, well ideally it would be in
 relation to a proper fix to NetBSD's mktime().  :-)
 
 In any case it certainly isn't a standards issue -- either fix NetBSD or
 not, but either way let emacs' configure continue to check for the bug
 and to complain and use its own mktime() if necessary, as doing anything
 else will cause bugs to appear that do not occur on any other systems.
 
 -- 
 						Greg A. Woods
 
 H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <woods@robohack.ca>
 Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>