91/3b67f9fc28050c6f4172f142e675ad8dfb5b66

   1 Return-Path: <prvs=505a806dc=jrosenthal@jhu.edu>\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 ED997431FB6\r
   6         for <notmuch@notmuchmail.org>; Thu, 14 Jun 2012 10:35:49 -0700 (PDT)\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 scEMnLbK3b8Q for <notmuch@notmuchmail.org>;\r
  16         Thu, 14 Jun 2012 10:35:47 -0700 (PDT)\r
  17 X-Greylist: delayed 3602 seconds by postgrey-1.32 at olra;\r
  18         Thu, 14 Jun 2012 10:35:47 PDT\r
  19 Received: from smtpauth.johnshopkins.edu (smtpauth.johnshopkins.edu\r
  20         [162.129.8.201]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
  21         (No client certificate requested)\r
  22         by olra.theworths.org (Postfix) with ESMTPS id 3880A431FAE\r
  23         for <notmuch@notmuchmail.org>; Thu, 14 Jun 2012 10:35:47 -0700 (PDT)\r
  24 X-IronPort-Anti-Spam-Filtered: true\r
  25 X-IronPort-Anti-Spam-Result: Ak4JACQS2k8KoSES/2dsb2JhbABFtA0DgjOCGAEBBAF+CwsNCwklDwEsGwYBEogGsRCJBIsyd4UaA5sXA4x/\r
  26 X-IronPort-AV: E=Sophos;i="4.75,770,1330923600"; d="scan'208";a="154617523"\r
  27 Received: from unknown (HELO watt) ([10.161.33.18])\r
  28         by ipex2.johnshopkins.edu with ESMTP/TLS/AES256-SHA;\r
  29         14 Jun 2012 12:35:44 -0400\r
  30 Received: from jkr by watt with local (Exim 4.76)\r
  31         (envelope-from <jrosenthal@jhu.edu>)\r
  32         id 1SfD1O-0002nv-3y; Thu, 14 Jun 2012 12:35:46 -0400\r
  33 From: Jesse Rosenthal <jrosenthal@jhu.edu>\r
  34 To: Tomi Ollila <tomi.ollila@iki.fi>, notmuch@notmuchmail.org\r
  35 Subject: Re: [PATCH] emacs: derive correct timestamp in FCC unique name\r
  36 In-Reply-To: <m2k3zamdo6.fsf@guru.guru-group.fi>\r
  37 References: <87d353ezyw.fsf@jhu.edu> <m2k3zamdo6.fsf@guru.guru-group.fi>\r
  38 User-Agent: Notmuch/0.12~rc1 (http://notmuchmail.org) Emacs/24.1.50.1\r
  39         (i686-pc-linux-gnu)\r
  40 Date: Thu, 14 Jun 2012 12:35:46 -0400\r
  41 Message-ID: <871ulhhmvx.fsf@jhu.edu>\r
  42 MIME-Version: 1.0\r
  43 Content-Type: text/plain\r
  44 X-BeenThere: notmuch@notmuchmail.org\r
  45 X-Mailman-Version: 2.1.13\r
  46 Precedence: list\r
  47 List-Id: "Use and development of the notmuch mail system."\r
  48         <notmuch.notmuchmail.org>\r
  49 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  50         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  51 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  52 List-Post: <mailto:notmuch@notmuchmail.org>\r
  53 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  54 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  55         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  56 X-List-Received-Date: Thu, 14 Jun 2012 17:35:50 -0000\r
  57 \r
  58 Hi, \r
  59 \r
  60 thanks for thinking this through.\r
  61 \r
  62 On Thu, 14 Jun 2012, Tomi Ollila <tomi.ollila@iki.fi> wrote:\r
  63 > Alternatives:\r
  64 >\r
  65 > 1) Use current patch, filenames will have extra '-' in 2038 on 32-bit\r
  66 > systems.\r
  67 \r
  68 Well, that assumes there is still the same arithmetic operations -- the\r
  69 calendar issue will probably push them to either auto-convert to float\r
  70 or use bignum. But still, assuming that in 2038, people are still on\r
  71 32bit machines, it seems we should minimize the amount of things that\r
  72 need to be fixed. \r
  73 \r
  74 So I agree that...\r
  75 \r
  76 > 2) Drop 'timeid' and replace it with (float-time) in `format` call a few\r
  77 > lines in original source after the patch context below -- No idea\r
  78 > how (float-time) works on 32-bit systems after 2038.\r
  79 \r
  80 is probably the best. They'll have to deal with their time_t (again,\r
  81 assuming the unlikely existence of 32bit machines then) but this doesn't\r
  82 depend on their arithemetic. \r
  83 \r
  84 I'll send a revision to this thread.\r
  85 \r
  86 > I suggest option #2.\r
  87 >\r
  88 > Tomi\r
  89 \r
  90 Thanks again,\r
  91 Jesse\r