From: Carsten Dominik <carsten.dominik@gmail.com>
To: Eric S Fraga <e.fraga@ucl.ac.uk>
Cc: nicholas.dokos@hp.com,
Emacs Org mode mailing list <emacs-orgmode@gnu.org>
Subject: Re: dates before 1970
Date: Fri, 11 Mar 2011 12:36:13 +0100 [thread overview]
Message-ID: <BA0DF733-ACDC-4653-A412-B48EFB8BDD29@gmail.com> (raw)
In-Reply-To: <87ei6ehwld.fsf@ucl.ac.uk>
On Mar 11, 2011, at 9:47 AM, Eric S Fraga wrote:
> Nick Dokos <nicholas.dokos@hp.com> writes:
>
>> Eric S Fraga <e.fraga@ucl.ac.uk> 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 safe.
And then hope that by 2038, all computers will use 64 bit integers....
- Carsten
next prev parent reply other threads:[~2011-03-11 11:36 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-10 21:00 dates before 1970 Eric S Fraga
2011-03-10 23:06 ` Nick Dokos
2011-03-11 8:31 ` Bastien
2011-03-11 8:52 ` Carsten Dominik
2011-03-13 7:39 ` Carsten Dominik
2011-03-13 20:08 ` Eric S Fraga
2011-03-14 7:40 ` Carsten Dominik
2011-03-14 9:58 ` Bastien
2011-03-11 8:47 ` Eric S Fraga
2011-03-11 11:36 ` Carsten Dominik [this message]
2011-03-11 12:00 ` Eric S Fraga
2011-03-11 15:28 ` Carsten Dominik
2011-03-11 17:56 ` Gregor Zattler
2011-03-12 22:38 ` Robert Horn
2011-03-11 16:30 ` Nick Dokos
2011-03-14 10:21 ` Carsten Dominik
2011-03-14 15:11 ` Nick Dokos
2011-03-14 17:02 ` Carsten Dominik
2011-03-14 17:13 ` Nick Dokos
2011-03-14 18:12 ` Achim Gratz
2011-03-15 7:24 ` Carsten Dominik
2011-03-11 16:16 ` Nick Dokos
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BA0DF733-ACDC-4653-A412-B48EFB8BDD29@gmail.com \
--to=carsten.dominik@gmail.com \
--cc=e.fraga@ucl.ac.uk \
--cc=emacs-orgmode@gnu.org \
--cc=nicholas.dokos@hp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).