From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 38906431FAF for ; Sun, 4 Nov 2012 20:51:06 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqrONA2I1i6P for ; Sun, 4 Nov 2012 20:51:02 -0800 (PST) Received: from foo.net (70-36-235-136.dsl.static.sonic.net [70.36.235.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 43D7D431FAE for ; Sun, 4 Nov 2012 20:51:02 -0800 (PST) Received: from foo.net (localhost [127.0.0.1]) by foo.net (8.14.5+Sun/8.14.5) with ESMTP id qA54oxOX004595; Sun, 4 Nov 2012 20:50:59 -0800 (PST) To: Jani Nikula Subject: =?UTF-8?B?UmU6IFtQQVRDSCAxMC8xMF0gdGltZWdtOiBhZGQgcG9ydGFibGUg?= =?UTF-8?B?aW1wbGVtZW50YXRpb24gKFNvbGFyaXMgc3VwcG9ydCkg?= In-Reply-To: Your message of "Sun, 04 Nov 2012 22:58:26 +0200." <87ip9lf5l9.fsf@nikula.org> Date: Sun, 04 Nov 2012 20:50:59 -0800 Message-ID: <4594.1352091059@foo.net> From: Blake Jones X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (foo.net [127.0.0.1]); Sun, 04 Nov 2012 20:50:59 -0800 (PST) Cc: notmuch@notmuchmail.org X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 04:51:06 -0000 > That is a valid point. Yet it doesn't change the fact that I'd prefer > to use timegm() where available. Internally, glibc uses the same code > to implement both timegm() and mktime(), and I'd hate it if the > results were subtly different depending on whether the time zone was > specified in the input or not. That's fine with me. > That said, I'm not opposed to using your simple timegm() alternative > in the compat code if you think it's good enough to get you going on > Solaris. I think it is, assuming you don't plan to use tm_wday or tm_yday in your parse-time-string code, and that you don't plan to depend on the side effect of timegm() canonicalizing the passed-in "struct tm". > As to solving the compat linking problem, I think the patch at the end > of this message should fix it. Please try that with the regular > notmuch approach to portability. The general idea is to keep > parse-time-string as independent as possible from the rest of notmuch > (possibly turning it into a dynamic library and a package of its own > eventually), but I think including compat.h is an acceptable exception > to make. Yeah, this seems to work. I'll update my patch set accordingly. Blake