From: Carsten Dominik <carsten.dominik@gmail.com>
To: Bastien Guerry <bzg@altern.org>
Cc: Eric S Fraga <ucecesf@ucl.ac.uk>,
Emacs Org mode mailing list <emacs-orgmode@gnu.org>,
"nicholas.dokos@hp.com Dokos" <nicholas.dokos@hp.com>
Subject: Re: dates before 1970
Date: Sun, 13 Mar 2011 08:39:13 +0100 [thread overview]
Message-ID: <C4308AF9-4D46-4205-B9DE-10F1F651CB23@gmail.com> (raw)
In-Reply-To: <87hbbaoy6l.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 2703 bytes --]
Hi everyone,
On 11.3.2011, at 09:31, Bastien wrote:
> Hi,
>
> Nick Dokos <nicholas.dokos@hp.com> writes:
>
>> So I'd guess raising an exception might be the simplest way to deal with
>> this. Here's a patch to try out:
>
> This patch has side-effects that Carsten have been recently exploring a
> bit. Those side-effects seem to depend on how Emacs has been compiled.
>
> For now it's best to stick to this restriction.
I am attaching a patch which tries to implement some kind of a
solution for this problem. The patch introduces a new variable
which will allow you to use dates outside the safe range 1970-2037
once you have convinced yourself that all Emacs implementation you
are likely to use now and in the future will support the extended
range. To be clear, I do not recommend to make use of this, the danger
that you will find yourself on a system where this issue is not
resolved is not negligible. That is also why I would recommend
the default `t' for this variable, and why I will continue to use diary-sexp
dates for the few dates where I need a greater range.
The patch also introduces a warning with a beep when Org has forced the year,
which, I think, was really the main concern in this thread.
Here is the docstring of the new variable - it explains what is going on.
(defcustom org-read-date-force-compatible-dates t
"Should date/time prompt force dates that are guaranteed to work in Emacs?
Depending on the system Emacs is running on, certain dates cannot
be represented with the type used internally to represent time.
Dates between 1970-1-1 and 2038-1-1 can always be represented
correctly. Some systems allow for earlier dates, some for later,
some for both. One way to find out it to insert any date into an
Org buffer, putting the cursor on the year and hitting S-up and
S-down to test the range.
When this variable is set to t, the date/time prompt will not let
you specify dates outside the 1970-2037 range, so it is certain that
these dates will work in whatever version of Emacs you are
running, and also that you can move a file from one Emacs implementation
to another. WHenever Org is forcing the year for you, it will display
a message and beep.
When this variable is nil, Org will check if the date is
representable in the specific Emacs implementation you are using.
If not, it will force a year, usually the current year, and beep
to remind you. Currently this setting is not recommended because
the likelihood that you will open your Org files in an Emacs that
has limited date range is not negligible.
A workaround for this problem is to use diary sexp dates for time
stamps outside of this range."
:group 'org-time
:type 'boolean)
[-- Attachment #2: 0001-Improve-handling-of-years-with-limitations-on-repres.patch --]
[-- Type: application/octet-stream, Size: 5783 bytes --]
From 138615942fe12b40f8fbb1de5ead5ae5960032f3 Mon Sep 17 00:00:00 2001
From: Carsten Dominik <carsten.dominik@gmail.com>
Date: Sun, 13 Mar 2011 08:06:22 +0100
Subject: [PATCH] Improve handling of years with limitations on representable dates
* lisp/org.el (org-read-date-force-compatible-dates): New option.
(org-read-date, org-read-date-analyze): Check representable date range.
* doc/org.texi (The date/time prompt): Document date range protection.
New variable `org-read-date-force-compatible-dates' to control
handling of dates.
---
doc/org.texi | 12 ++++++++++--
lisp/org.el | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 62 insertions(+), 4 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index e13af4b..dd6d945 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -5394,9 +5394,17 @@ The function understands English month and weekday abbreviations. If
you want to use unabbreviated names and/or other languages, configure
the variables @code{parse-time-months} and @code{parse-time-weekdays}.
+@vindex org-read-date-force-compatible-dates
+Not all dates can be represented in a given Emacs implementation. By default
+Org mode forces dates into the compatibility range 1970--2037 which works on
+all Emacs implementations. If you want to use dates outside of this range,
+read the docstring of the variable
+@code{org-read-date-force-compatible-dates}.
+
You can specify a time range by giving start and end times or by giving a
-start time and a duration (in HH:MM format). Use `-' or `-@{@}-' as the separator
-in the former case and use '+' as the separator in the latter case. E.g.@:
+start time and a duration (in HH:MM format). Use `-' or `-@{@}-' as the
+separator in the former case and use '+' as the separator in the latter
+case. E.g.@:
@example
11am-1:15pm @result{} 11:00-13:15
diff --git a/lisp/org.el b/lisp/org.el
index 96ad8ff..a145de6 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -2651,6 +2651,36 @@ This may t or nil, or the symbol `org-read-date-prefer-future'."
(const :tag "Never" nil)
(const :tag "Always" t)))
+(defcustom org-read-date-force-compatible-dates t
+ "Should date/time prompt force dates that are guaranteed to work in Emacs?
+
+Depending on the system Emacs is running on, certain dates cannot
+be represented with the type used internally to represent time.
+Dates between 1970-1-1 and 2038-1-1 can always be represented
+correctly. Some systems allow for earlier dates, some for later,
+some for both. One way to find out it to insert any date into an
+Org buffer, putting the cursor on the year and hitting S-up and
+S-down to test the range.
+
+When this variable is set to t, the date/time prompt will not let
+you specify dates outside the 1970-2037 range, so it is certain that
+these dates will work in whatever version of Emacs you are
+running, and also that you can move a file from one Emacs implementation
+to another. WHenever Org is forcing the year for you, it will display
+a message and beep.
+
+When this variable is nil, Org will check if the date is
+representable in the specific Emacs implementation you are using.
+If not, it will force a year, usually the current year, and beep
+to remind you. Currently this setting is not recommended because
+the likelihood that you will open your Org files in an Emacs that
+has limited date range is not negligible.
+
+A workaround for this problem is to use diary sexp dates for time
+stamps outside of this range."
+ :group 'org-time
+ :type 'boolean)
+
(defcustom org-read-date-display-live t
"Non-nil means display current interpretation of date prompt live.
This display will be in an overlay, in the minibuffer."
@@ -14503,6 +14533,13 @@ user."
(setq final (org-read-date-analyze ans def defdecode))
+ (when org-read-date-analyze-forced-year
+ (message "Year was forced into %s"
+ (if org-read-date-force-compatible-dates
+ "compatible range (1970-2037)"
+ "range representable on this machine"))
+ (ding))
+
;; One round trip to get rid of 34th of August and stuff like that....
(setq final (decode-time (apply 'encode-time final)))
@@ -14520,6 +14557,7 @@ user."
(defvar defdecode)
(defvar with-time)
(defvar org-read-date-analyze-futurep nil)
+(defvar org-read-date-analyze-forced-year nil)
(defun org-read-date-display ()
"Display the current date prompt interpretation in the minibuffer."
(when org-read-date-display-live
@@ -14562,7 +14600,8 @@ user."
delta deltan deltaw deltadef year month day
hour minute second wday pm h2 m2 tl wday1
iso-year iso-weekday iso-week iso-year iso-date futurep kill-year)
- (setq org-read-date-analyze-futurep nil)
+ (setq org-read-date-analyze-futurep nil
+ org-read-date-analyze-forced-year nil)
(when (string-match "\\`[ \t]*\\.[ \t]*\\'" ans)
(setq ans "+0"))
@@ -14720,7 +14759,18 @@ 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
+ ;; Check of the date is representable
+ (if org-read-date-force-compatible-dates
+ (progn
+ (if (< year 1970)
+ (setq year 1970 org-read-date-analyze-forced-year t))
+ (if (> year 2037)
+ (setq year 2037 org-read-date-analyze-forced-year t)))
+ (condition-case nil
+ (encode-time second minute hour day month year)
+ (error
+ (setq year (nth 5 defdecode))
+ (setq org-read-date-analyze-forced-year t))))
(setq org-read-date-analyze-futurep futurep)
(list second minute hour day month year)))
--
1.7.1.575.gf526
[-- Attachment #3: Type: text/plain, Size: 2 bytes --]
next prev parent reply other threads:[~2011-03-13 7:39 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 [this message]
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
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=C4308AF9-4D46-4205-B9DE-10F1F651CB23@gmail.com \
--to=carsten.dominik@gmail.com \
--cc=bzg@altern.org \
--cc=emacs-orgmode@gnu.org \
--cc=nicholas.dokos@hp.com \
--cc=ucecesf@ucl.ac.uk \
/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).