From: Blake Jones Date: Mon, 5 Nov 2012 18:33:12 +0000 (+1600) Subject: Re: [PATCH 10/10] timegm: add portable implementation (Solaris support) X-Git-Url: http://git.tremily.us/gitweb.cgi?a=commitdiff_plain;h=6dd9779f505f00e4de1dd9c4d4fc2148252905aa;p=notmuch-archives.git Re: [PATCH 10/10] timegm: add portable implementation (Solaris support) --- diff --git a/73/ee181548f61afc29f56c9dd7e79af9b36f31e5 b/73/ee181548f61afc29f56c9dd7e79af9b36f31e5 new file mode 100644 index 000000000..21b801445 --- /dev/null +++ b/73/ee181548f61afc29f56c9dd7e79af9b36f31e5 @@ -0,0 +1,107 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 372A3431FB6 + for ; Mon, 5 Nov 2012 10:33:21 -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 NI2KjQv8GENl for ; + Mon, 5 Nov 2012 10:33:20 -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 6B538431FAE + for ; Mon, 5 Nov 2012 10:33:20 -0800 (PST) +Received: from foo.net (localhost [127.0.0.1]) + by foo.net (8.14.5+Sun/8.14.5) with ESMTP id qA5IXCca010300; + Mon, 5 Nov 2012 10:33:12 -0800 (PST) +To: Tomi Ollila +Subject: Re: [PATCH 10/10] timegm: add portable implementation (Solaris + support) +In-Reply-To: Your message of "Mon, 05 Nov 2012 19:36:47 +0200." + +Date: Mon, 05 Nov 2012 10:33:12 -0800 +Message-ID: <10299.1352140392@foo.net> +From: Blake Jones +X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 + (foo.net [127.0.0.1]); Mon, 05 Nov 2012 10:33:13 -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 18:33:21 -0000 + +>> The other approaches rely on letting libc do all the hard work of +>> time zone manipulation, and then reading the tea leaves to find a way +>> to undo it. +> +> Did you look at the gnu libc version -- I bet it is pretty hairy... + +I didn't look at either the GNU or the Solaris libc version. But the +file that implements the timezone handling (and localtime(), mktime(), +etc.) in Solaris' libc is nearly 3000 lines of code, so I suspect +there's an awful lot of stuff going on. + +>> For what it's worth, I used the attached program to test my +>> implementation, and it passed. +> +> Thanks, It's nice to see your simple implementation passes these +> tests... +> +> Just for curiosity: What do you think lacks in your timegm() that it +> could not be promoted as 'complete timegm() solution'. + +Well, since there isn't a standard for timegm(), I'm comparing it to +what glibc and BSD do. The glibc mktime() man page, for example, +mentions that mktime() modifies the fields of the tm structure as +follows: + + - tm_wday and tm_yday are set to values determined from the contents + of the other fields + + - if structure members are outside their valid interval, they will + be normalized (so that, for example, 40 October is changed into 9 + November) + + - tm_isdst is set (regardless of its initial value) to a positive + value or to 0, respectively, to indicate whether DST is or is not + in effect at the specified time. + + - Calling mktime() also sets the external variable tzname with + information about the current timezone. + +The corresponding timegm() man page for glibc doesn't say whether +timegm() does the same thing, but I would assume it does. The FreeBSD +timegm() man page says that its version does update the fields of the +"tm" structure, like its mktime() implementation. + +My implementation of timegm() does none of these things. It treats the +passed-in "struct tm" as constant, and just returns a valid time_t. If +you really wanted to make this mktime() be as capable as the ones in the +GNU and BSD libc's, you could have it turn around and call gmtime_r() on +the generated time_t, and pass the original "struct tm" to gmtime_r(). +Personally, I think this is unnecessary overloading of a function that +does this one thing just fine, and in practice Jani's code doesn't seem +to need it, so I didn't bother. + +> In any way, including this timegm() function in compat suits me fine. + +Great. + +Blake