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: Re: Time not representable Date: Fri, 11 Mar 2011 09:46:09 -0800 Organization: UCLA Computer Science Department Message-ID: <4D7A5FE1.5000400@cs.ucla.edu> References: <1B714A80-0584-499D-BB28-A7970FE60C28@gmail.com> 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 1299865637 4885 80.91.229.12 (11 Mar 2011 17:47:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 11 Mar 2011 17:47:17 +0000 (UTC) Cc: Bastien Guerry , Emacs developers To: Carsten Dominik Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 11 18:47:12 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Py6Qi-0003sJ-KB for ged-emacs-devel@m.gmane.org; Fri, 11 Mar 2011 18:47:12 +0100 Original-Received: from localhost ([127.0.0.1]:51424 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Py6Qi-0004kO-4m for ged-emacs-devel@m.gmane.org; Fri, 11 Mar 2011 12:47:12 -0500 Original-Received: from [140.186.70.92] (port=37431 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Py6Pn-0004Md-Rj for emacs-devel@gnu.org; Fri, 11 Mar 2011 12:46:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Py6Pk-00071l-D9 for emacs-devel@gnu.org; Fri, 11 Mar 2011 12:46:15 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:49877) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Py6Pk-00071S-30 for emacs-devel@gnu.org; Fri, 11 Mar 2011 12:46:12 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id B4AE939E80F9; Fri, 11 Mar 2011 09:46:10 -0800 (PST) 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 YpqkytkqSHHA; Fri, 11 Mar 2011 09:46:10 -0800 (PST) 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 3563339E80F0; Fri, 11 Mar 2011 09:46:10 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 In-Reply-To: <1B714A80-0584-499D-BB28-A7970FE60C28@gmail.com> 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.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:137116 Archived-At: On 03/11/2011 05:01 AM, Carsten Dominik wrote: > Why is it that these things are different on different systems? Is > this under the control of Emacs, or does this depend on system > libraries which are being used? Both. Time stamps on most modern systems have nanosecond resolution, but Emacs's internal time stamps only use microsecond resolution. This means (for example) that Emacs cannot determine that one file is newer than another, even when it is newer. This bug really should get fixed at some point. In addition to resolution problems, there are also the range problems that you alluded to. time_t is usually a signed 32-bit or 64-bit integer; a few systems use unsigned integers, and several use signed integers but do not allow negative values. (Emacs in theory could use 32-bit EMACS_INT internally on a system with 64-bit time_t, but I expect that combination is rare.) You have to be careful about inferring ranges from behavior, though, because when Emacs converts times, it sometimes doesn't check for overflow. This means you can get undefined behavior if you use time stamps that cannot be represented internally. For example, (encode-time 0 0 0 1 1 1152921504606846976) returns the obviously-bogus value (-948597 62170) on my RHEL 5.5 x86-64 host, whereas it correctly reports a "Specified time is not representable" error on my Ubuntu 10.10 x86 host. This is a bug that should get fixed at some point too, though I expect it's less important in practice than the nanosecond-resolution bug.