From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: nanosecond-resolution time stamps Date: Thu, 30 Jun 2011 23:59:27 -0700 Organization: UCLA Computer Science Department Message-ID: <4E0D704F.4070304@cs.ucla.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1309503643 11911 80.91.229.12 (1 Jul 2011 07:00:43 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 1 Jul 2011 07:00:43 +0000 (UTC) To: Emacs Development Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 01 09:00:39 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QcXiP-0003HA-Vu for ged-emacs-devel@m.gmane.org; Fri, 01 Jul 2011 09:00:38 +0200 Original-Received: from localhost ([::1]:38367 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcXiP-0008D2-8r for ged-emacs-devel@m.gmane.org; Fri, 01 Jul 2011 03:00:37 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:38924) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcXhT-0007yN-Ti for emacs-devel@gnu.org; Fri, 01 Jul 2011 02:59:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QcXhQ-0001eF-Hd for emacs-devel@gnu.org; Fri, 01 Jul 2011 02:59:39 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:39810) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcXhP-0001e0-Ol for emacs-devel@gnu.org; Fri, 01 Jul 2011 02:59:36 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 50D4139E8106 for ; Thu, 30 Jun 2011 23:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBrt7VKeRj-O for ; Thu, 30 Jun 2011 23:59:33 -0700 (PDT) Original-Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 7657D39E80F2 for ; Thu, 30 Jun 2011 23:59:33 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 131.179.128.62 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:141320 Archived-At: Emacs currently uses microsecond-resolution time stamps internally, whereas GNU and similar operating systems have all gone to nanosecond-resolution time stamps internally. This mismatch leads to problems, for example, Emacs mishandles file time stamps when it copies them. I have prepared a set of patches to fix this, and would like them to be considered for Emacs 24 if possible or for a later version if not. I'll send them in other email messages shortly. The basic idea of these patches is to add 3 digits to the time stamp format. For example, currently (current-time) might return (19981 28208 421496); with the patches, it returns (19981 28208 421496053) at exactly the same instant. That is, the last number of the Emacs internal time stamp now counts nanoseconds, not microseconds. (On older machines that do not support finegrained time stamps the trailing digits are always 000.) If we're on a 32-bit machine and the nanosecond count exceeds 2**29, Emacs falls back on floating point to represent the out-of-range integer. (There is a similar problem, by the way, with the *first* number being out of range for integers, on some platforms, and the patches use the same solution there.) This change to the internal time stamp format is an incompatible change and might cause problems with external packages. If you like, it'd be easy to alter to the patch to use any other reasonable format. For example, if you'd prefer the format (19981 28208 421496 053) (i.e., the sub-microsecond count is appended), I could easily do that. But I thought I'd get my current code out the door, for review. (I'm sending this first message now, just a few nanoseconds before June ends, since that's the cutoff for Emacs 24 changes....)