From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: dates before 1970 Date: Thu, 10 Mar 2011 18:06:33 -0500 Message-ID: <5422.1299798393@alphaville.usa.hp.com> References: <87ei6en127.fsf@ucl.ac.uk> Reply-To: nicholas.dokos@hp.com Return-path: Received: from [140.186.70.92] (port=46039 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PxowH-0004vu-E5 for emacs-orgmode@gnu.org; Thu, 10 Mar 2011 18:06:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PxowF-0005f7-TO for emacs-orgmode@gnu.org; Thu, 10 Mar 2011 18:06:37 -0500 Received: from g4t0017.houston.hp.com ([15.201.24.20]:22045) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PxowF-0005et-Nw for emacs-orgmode@gnu.org; Thu, 10 Mar 2011 18:06:35 -0500 In-Reply-To: Message from Eric S Fraga of "Thu, 10 Mar 2011 21:00:16 GMT." <87ei6en127.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 Eric S Fraga wrote: > This is a sort of bug report but possibly more a curiosity... > > 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? > > To be precise, I get the wrong date recorded if I try: > > C-c ! 1968-12-10 RET > > (where C-c ! is =org-time-stamp-inactive=). > The result is =[2011-12-10 Sat]= > > 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. > Good one! The culprit is org-read-date-analyze which near the end contains this snippet of code: ,---- | ... | (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))) `---- 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). 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 >=1970 requirement). So I'd guess raising an exception might be the simplest way to deal with this. Here's a patch to try out: --8<---------------cut here---------------start------------->8--- diff --git a/lisp/org.el b/lisp/org.el index 92f2406..b9acf11 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -14718,7 +14718,8 @@ user." (nth 2 tl)) (setq org-time-was-given t)) (if (< year 100) (setq year (+ 2000 year))) - (if (< year 1970) (setq year (nth 5 defdecode))) ; not representable +; (if (< year 1970) (setq year (nth 5 defdecode))) ; not representable + (if (< year 1970) (error "Year must be >= 1970")) (setq org-read-date-analyze-futurep futurep) (list second minute hour day month year))) --8<---------------cut here---------------end--------------->8--- I think it does not break anything but I'm not sure I like it much. Patchwork note: this should not be applied without a lot more thought and experimentation. Nick