dc/534afcf9aa4ce464c7e8978132fb7abae9b03b

   1 Return-Path: <tomi.ollila@iki.fi>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id D1549431FB6\r
   6         for <notmuch@notmuchmail.org>; Mon,  5 Nov 2012 09:36:49 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 0\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
  12         autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id WXqPXLYzdUQL for <notmuch@notmuchmail.org>;\r
  16         Mon,  5 Nov 2012 09:36:48 -0800 (PST)\r
  17 Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34])\r
  18         by olra.theworths.org (Postfix) with ESMTP id C2783431FAE\r
  19         for <notmuch@notmuchmail.org>; Mon,  5 Nov 2012 09:36:48 -0800 (PST)\r
  20 Received: from guru.guru-group.fi (localhost [IPv6:::1])\r
  21         by guru.guru-group.fi (Postfix) with ESMTP id 3E178100094;\r
  22         Mon,  5 Nov 2012 19:36:48 +0200 (EET)\r
  23 From: Tomi Ollila <tomi.ollila@iki.fi>\r
  24 To: Blake Jones <blakej@foo.net>\r
  25 Subject: Re: [PATCH 10/10] timegm: add portable implementation (Solaris\r
  26         support)\r
  27 In-Reply-To: <2592.1352130442@foo.net>\r
  28 References: <2592.1352130442@foo.net>\r
  29 User-Agent: Notmuch/0.14+81~gb8371cd (http://notmuchmail.org) Emacs/24.2.1\r
  30         (x86_64-unknown-linux-gnu)\r
  31 X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL\r
  32         $[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F\r
  33         !)g;OY^,BjTbr)Np:%c_o'jj,Z\r
  34 Date: Mon, 05 Nov 2012 19:36:47 +0200\r
  35 Message-ID: <m2a9uwyms0.fsf@guru.guru-group.fi>\r
  36 MIME-Version: 1.0\r
  37 Content-Type: text/plain\r
  38 Cc: notmuch@notmuchmail.org\r
  39 X-BeenThere: notmuch@notmuchmail.org\r
  40 X-Mailman-Version: 2.1.13\r
  41 Precedence: list\r
  42 List-Id: "Use and development of the notmuch mail system."\r
  43         <notmuch.notmuchmail.org>\r
  44 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  45         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  46 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  47 List-Post: <mailto:notmuch@notmuchmail.org>\r
  48 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  49 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  50         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  51 X-List-Received-Date: Mon, 05 Nov 2012 17:36:50 -0000\r
  52 \r
  53 On Mon, Nov 05 2012, Blake Jones wrote:\r
  54 \r
  55 >> Yet another idea for an alternative. Compile by entering 'sh xtimegm.c'\r
  56 >> and then run ./xtimegm\r
  57 >> \r
  58 >> Simple cases seems to work. Dst change may (or then may not) give one\r
  59 >> hour difference to the expected. The test "coverage" could be easily\r
  60 >> expanded to that ;)\r
  61 >> \r
  62 >> Hmm, I also found this:\r
  63 >> http://lists.gnu.org/archive/html/bug-gnulib/2003-09/msg00004.html\r
  64 >> which does 2 mktime's and one gmtime_r (without allocating tg!)...\r
  65 >> Pick any of these 3 -- or something different (e.g. less NIH if there is)\r
  66 >\r
  67 > Of these two, I would probably lean slightly toward the latter, in that\r
  68 > it relies more on libc for the time zone handling logic.\r
  69 >\r
  70 > But in general, this seems to me like a case where an explicit\r
  71 > implementation like mine is less prone to failure, because it doesn't\r
  72 > need to worry about time zones at all. \r
  73 \r
  74 Good point.\r
  75 \r
  76 > The other approaches rely on\r
  77 > letting libc do all the hard work of time zone manipulation, and then\r
  78 > reading the tea leaves to find a way to undo it.\r
  79 \r
  80 Did you look at the gnu libc version -- I bet it is pretty hairy...\r
  81 \r
  82 >  I would guess that if\r
  83 > some change in the time standards is going to break one of these\r
  84 > implementations, it's going to be some new time zone specification, not\r
  85 > a change in the number of days in a month. :)\r
  86 >\r
  87 > For what it's worth, I used the attached program to test my\r
  88 > implementation, and it passed.\r
  89 \r
  90 Thanks, It's nice to see your simple implementation passes these tests...\r
  91 \r
  92 Just for curiosity: What do you think lacks in your timegm() that it could\r
  93 not be promoted as 'complete timegm() solution'.\r
  94 \r
  95 In any way, including this timegm() function in compat suits me fine.\r
  96 \r
  97 >\r
  98 > Blake\r
  99 >\r
 100 \r
 101 Tomi\r