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 D1549431FB6 for ; Mon, 5 Nov 2012 09:36:49 -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 WXqPXLYzdUQL for ; Mon, 5 Nov 2012 09:36:48 -0800 (PST) Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34]) by olra.theworths.org (Postfix) with ESMTP id C2783431FAE for ; Mon, 5 Nov 2012 09:36:48 -0800 (PST) Received: from guru.guru-group.fi (localhost [IPv6:::1]) by guru.guru-group.fi (Postfix) with ESMTP id 3E178100094; Mon, 5 Nov 2012 19:36:48 +0200 (EET) From: Tomi Ollila To: Blake Jones Subject: Re: [PATCH 10/10] timegm: add portable implementation (Solaris support) In-Reply-To: <2592.1352130442@foo.net> References: <2592.1352130442@foo.net> User-Agent: Notmuch/0.14+81~gb8371cd (http://notmuchmail.org) Emacs/24.2.1 (x86_64-unknown-linux-gnu) X-Face: HhBM'cA~ MIME-Version: 1.0 Content-Type: text/plain 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 17:36:50 -0000 On Mon, Nov 05 2012, Blake Jones wrote: >> Yet another idea for an alternative. Compile by entering 'sh xtimegm.c' >> and then run ./xtimegm >> >> Simple cases seems to work. Dst change may (or then may not) give one >> hour difference to the expected. The test "coverage" could be easily >> expanded to that ;) >> >> Hmm, I also found this: >> http://lists.gnu.org/archive/html/bug-gnulib/2003-09/msg00004.html >> which does 2 mktime's and one gmtime_r (without allocating tg!)... >> Pick any of these 3 -- or something different (e.g. less NIH if there is) > > Of these two, I would probably lean slightly toward the latter, in that > it relies more on libc for the time zone handling logic. > > But in general, this seems to me like a case where an explicit > implementation like mine is less prone to failure, because it doesn't > need to worry about time zones at all. Good point. > 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 would guess that if > some change in the time standards is going to break one of these > implementations, it's going to be some new time zone specification, not > a change in the number of days in a month. :) > > 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'. In any way, including this timegm() function in compat suits me fine. > > Blake > Tomi