From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Carsten Dominik Newsgroups: gmane.emacs.devel Subject: Re: Time not representable Date: Sat, 12 Mar 2011 22:13:28 +0000 (UTC) Message-ID: References: <1B714A80-0584-499D-BB28-A7970FE60C28@gmail.com> <4D7A5FE1.5000400@cs.ucla.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1299968120 7149 80.91.229.12 (12 Mar 2011 22:15:20 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 12 Mar 2011 22:15:20 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 12 23:15:16 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 1PyX5f-0005ug-Cg for ged-emacs-devel@m.gmane.org; Sat, 12 Mar 2011 23:15:15 +0100 Original-Received: from localhost ([127.0.0.1]:45344 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PyX5e-00048G-39 for ged-emacs-devel@m.gmane.org; Sat, 12 Mar 2011 17:15:14 -0500 Original-Received: from [140.186.70.92] (port=47766 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PyX5Z-00048B-9K for emacs-devel@gnu.org; Sat, 12 Mar 2011 17:15:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PyX5Y-0001pL-2V for emacs-devel@gnu.org; Sat, 12 Mar 2011 17:15:09 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:57251) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PyX5X-0001p4-Ma for emacs-devel@gnu.org; Sat, 12 Mar 2011 17:15:07 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PyX5U-0005rM-H7 for emacs-devel@gnu.org; Sat, 12 Mar 2011 23:15:04 +0100 Original-Received: from s5146846e.adsl.wanadoo.nl ([81.70.132.110]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 12 Mar 2011 23:15:04 +0100 Original-Received: from carsten.dominik by s5146846e.adsl.wanadoo.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 12 Mar 2011 23:15:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 48 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 81.70.132.110 (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Firefox/3.6.15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 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:137172 Archived-At: Paul Eggert cs.ucla.edu> writes: > > 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. Hi Paul (and Andreas) thanks for the information. So if a system uses a signed 64 bit integer, then the representation problems will be fixed automatically, without further changes in Emacs? This does sound hopeful! Is there anyone here who has a 64 bit system and con confirm that encode-time can handle times both before 1970 and after 2040 without any problems? - Carsten