From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Greg Troxel Newsgroups: gmane.lisp.guile.devel Subject: Re: 1.6.8 release candidate 0 available for testing. Date: 24 Oct 2005 21:29:38 -0400 Message-ID: References: <87u0fipkio.fsf@trouble.defaultvalue.org> <87y84taxzo.fsf@zip.com.au> <87fyqy8f3f.fsf@zip.com.au> <878xwj50or.fsf@zip.com.au> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1130203935 589 80.91.229.2 (25 Oct 2005 01:32:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 25 Oct 2005 01:32:15 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Oct 25 03:32:13 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EUDev-0002Pi-18 for guile-devel@m.gmane.org; Tue, 25 Oct 2005 03:31:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EUDeu-0004k0-F3 for guile-devel@m.gmane.org; Mon, 24 Oct 2005 21:31:24 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EUDdH-0003dm-Pd for guile-devel@gnu.org; Mon, 24 Oct 2005 21:29:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EUDdF-0003a8-Pc for guile-devel@gnu.org; Mon, 24 Oct 2005 21:29:43 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EUDdD-0003Zy-Ma for guile-devel@gnu.org; Mon, 24 Oct 2005 21:29:41 -0400 Original-Received: from [192.1.100.210] (helo=fnord.ir.bbn.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EUDdD-0006BP-OQ for guile-devel@gnu.org; Mon, 24 Oct 2005 21:29:39 -0400 Original-Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 0664C5286; Mon, 24 Oct 2005 21:29:39 -0400 (EDT) Original-To: guile-devel@gnu.org In-Reply-To: <878xwj50or.fsf@zip.com.au> Original-Lines: 46 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:5359 Archived-At: Kevin Ryde writes: > Greg Troxel writes: > > Straight "pass through" to libc sounds good to me. > > > and make the implementation set TZ before calling > > strftime (perhaps unless an implementation which guarantees to read > > tm_zone is detected). > > That might be slow. I notice what localtime does changing TZ is a > noticable slowdown with glibc. (It re-reads the timezone file(s) on > every TZ change.) > > I wonder if munging the global tzname[] variable would be enough. Bad > for multi-threading, but we've got issues with that in the time funcs > already. If we munge the variable or set TZ, then scheme strftime will have stricter semantics than C99. Also, I wonder if setting the variable is safe according to the standard which defines it; that seems dangerous. > > Perhaps don't set > > the non-C99 fields in what is used for the libc call to avoid > > nonportable expectations. > > I wouldn't deliberately break something just because it's not > portable. > > > The meta-issue I see here is about guile providing consistent behavior > > on all platforms. > > Though I see your point. I realize this is a tough call, but declining to provide more behavior than the relevant standard ensures that the original programmer finds the 'bug', rather than it later being a portability problem. > PS. I added "man 3 strftime" to the manual. Thanks, that will be helpful to some I think. -- Greg Troxel _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel