From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: dates before 1970 Date: Fri, 11 Mar 2011 12:36:13 +0100 Message-ID: References: <87ei6en127.fsf@ucl.ac.uk> <5422.1299798393@alphaville.usa.hp.com> <87ei6ehwld.fsf@ucl.ac.uk> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: Received: from [140.186.70.92] (port=35971 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Py0dm-0004WN-U3 for emacs-orgmode@gnu.org; Fri, 11 Mar 2011 06:36:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Py0dl-00051z-Jh for emacs-orgmode@gnu.org; Fri, 11 Mar 2011 06:36:18 -0500 Received: from mail-wy0-f169.google.com ([74.125.82.169]:56171) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Py0dl-00051t-DM for emacs-orgmode@gnu.org; Fri, 11 Mar 2011 06:36:17 -0500 Received: by wyf19 with SMTP id 19so2703632wyf.0 for ; Fri, 11 Mar 2011 03:36:16 -0800 (PST) In-Reply-To: <87ei6ehwld.fsf@ucl.ac.uk> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Eric S Fraga Cc: nicholas.dokos@hp.com, Emacs Org mode mailing list On Mar 11, 2011, at 9:47 AM, Eric S Fraga wrote: > Nick Dokos writes: >=20 >> Eric S Fraga wrote: >>=20 >>> This is a sort of bug report but possibly more a curiosity... >>>=20 >>> I imagine this has something to do with time 0 in Unix but I cannot = seem >>> to be able to enter any date earlier than 1 Jan 1970 using C-c! = (say). >>> However, once I have entered a date (later than that), I can use >>> S- on the year to get to the date I want. This seems rather >>> inconsistent? >>>=20 >>> To be precise, I get the wrong date recorded if I try: >>>=20 >>> C-c ! 1968-12-10 RET >>>=20 >>> (where C-c ! is =3Dorg-time-stamp-inactive=3D). >>> The result is =3D[2011-12-10 Sat]=3D >>>=20 >>> The bug is not so much that I cannot input dates I want but that the >>> inactive timestamp generated is *incorrect* and yet there is no = error >>> message. >>>=20 >>=20 >> Good one! The culprit is org-read-date-analyze which near the end = contains >> this snippet of code: >>=20 >> ,---- >> | ... >> | (if (< year 100) (setq year (+ 2000 year))) >> | (if (< year 1970) (setq year (nth 5 defdecode))) ; not = representable >> | (setq org-read-date-analyze-futurep futurep) >> | (list second minute hour day month year))) >> `---- >>=20 >> The trouble is that the caller (org-read-date) takes the result and >> does a round-trip through the emacs time encode/decode functions to = make >> sure the result is sane. Dates before 1970 would break that (I get (0 = 9 >> 10 26 11 2033 6 nil -18000)) so it seems it wraps around to 2033 or >> so). >=20 > Yes, that makes sense. >=20 >> In addition, most callers of org-read-date call it with a non-nil >> to-time argument: that makes it return an emacs-encoded time (which = is >> then manipulated as such and which I believe has to satisfy the = >=3D1970 >> requirement). >>=20 >> So I'd guess raising an exception might be the simplest way to deal = with >> this. Here's a patch to try out: >=20 > This seems to work fine. Thanks. >=20 > I am glad, however, that I can enter any date and then use the = S- > etc. keys to get the date I want. Of course, I am not sure if = anything > else in org breaks as a result... org-sparse-tree with very old > scheduled dates seems to work. Haven't tried much else and I would > guess few would notice? THis is exactly the point, that it depends on how Emacs was compiled, = and what kind of integer is used in the date representation. Signed or = unsigend, 32 or 64 bits (I think). For example, Bastien can represent dates before 1970. I cannot. I can represent dates after 2038, Bastien cannot. The work-around is to use diary sexps for dates before 1970, that seems = to be safe. And then hope that by 2038, all computers will use 64 bit integers.... - Carsten