[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] dates before 1970

From: Carsten Dominik
Subject: Re: [O] dates before 1970
Date: Fri, 11 Mar 2011 12:36:13 +0100

On Mar 11, 2011, at 9:47 AM, Eric S Fraga wrote:

> Nick Dokos <address@hidden> writes:
>> Eric S Fraga <address@hidden> 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-<down> 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).
> Yes, that makes sense.
>> 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:
> This seems to work fine.  Thanks.
> I am glad, however, that I can enter any date and then use the S-<down>
> 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 
And then hope that by 2038, all computers will use 64 bit integers....

- Carsten

reply via email to

[Prev in Thread] Current Thread [Next in Thread]