From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id z2uAJKosBWA5bwAA0tVLHw (envelope-from ) for ; Mon, 18 Jan 2021 06:37:30 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id wNLoH6osBWCoNAAA1q6Kng (envelope-from ) for ; Mon, 18 Jan 2021 06:37:30 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 78BB8940480 for ; Mon, 18 Jan 2021 06:37:29 +0000 (UTC) Received: from localhost ([::1]:58946 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l1OAJ-0001LK-Ty for larch@yhetil.org; Mon, 18 Jan 2021 01:37:27 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:33166) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l1O8y-0001Jq-8d for emacs-orgmode@gnu.org; Mon, 18 Jan 2021 01:36:04 -0500 Received: from out1.migadu.com ([2001:41d0:2:863f::]:36080) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l1O8u-0006CG-4q for emacs-orgmode@gnu.org; Mon, 18 Jan 2021 01:36:04 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kyleam.com; s=key1; t=1610951754; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=jUpUrhIbfwaIoZqk5QIuvLZmAFFhp445XavscNLEt40=; b=d1dIHLUF+UAbahrRGLg6PNk8tg5C3EqiA0OLCuqqFqHDktduaFft5Gv4XUhC38pD6Dh4iZ 1KsC0FG45XSaD+CXpy9wc0Vt9J0lcUTM0P30iZju/Q7egkau3QwRm69/FWh4k6gsAu+qLZ igajEOAC4YsjsWlUnrI/wx0uBEtobIgG0VVj37fj1JxcjtXthnoEIMDJRKB193ZBoBjItX ZUI2gBHl7FUpFcImR5tKhnpsBDfSY0reCDrq5Vc8wEDcpxxKoYk5rClZ5Fx3POFG86LVdO gpRHq/uu4bbddUClruqLKOUrxH2dERkf0fown8BxAqil+ZOs9tEA+l9n7fQnTg== From: Kyle Meyer To: Richard Lawrence Subject: Re: Bug: incorrect timestamps with :time-prompt and datetrees In-Reply-To: <87ble2uuoa.fsf@aquinas> References: <87h7obh4ct.fsf@aquinas> <87eejfh0fm.fsf@aquinas> <87ble2uuoa.fsf@aquinas> Date: Mon, 18 Jan 2021 01:35:52 -0500 Message-ID: <87o8hm3g6v.fsf@kyleam.com> MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Auth-User: kyle@kyleam.com Received-SPF: pass client-ip=2001:41d0:2:863f::; envelope-from=kyle@kyleam.com; helo=out1.migadu.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.56 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=kyleam.com header.s=key1 header.b=d1dIHLUF; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: 78BB8940480 X-Spam-Score: -2.56 X-Migadu-Scanner: scn0.migadu.com X-TUID: zve1/viJpijv Richard Lawrence writes: > Hi everyone, > > Richard Lawrence writes: > >> I can now confirm that this is the problem. It looks like what is happening here >> is that the regex is meant to match a time range, but ends up matching >> the date: thus a string like "12-31 13:00" gets mangled to "12 13:00" >> and sent into org-read-date-analyze. > >> So I guess the solution is...a better regex is needed to cause this >> branch to fire only in the intended case, namely, a time range. > > Here is a patch for this issue. It uses a narrower regex to match a time > range. This regex requires time ranges to have ":MM" or an AM/PM > specification in the end time, to prevent mangling strings that are > interpreted as dates, like "11-12". Thanks for the detailed analysis and the patch. > This patch is a minimal change that gets the code working in the way > that seems to have been intended, so it seems worth applying to maint. Yes, seems so. The original change came in b61ff117b (org-capture.el: Set a correct time value with file+datetree+prompt, 2012-09-24), and I believe the related thread is . I'm okay with the minimal fix to the regexp, though I wonder if we can avoid the follow-up call to org-read-date-analyze entirely. I'm running out of time to test thoroughly tonight, but perhaps something like this (ignoring the potential cond->if cleanup): --8<---------------cut here---------------start------------->8--- diff --git a/lisp/org-capture.el b/lisp/org-capture.el index 038b24312..04e56d655 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -1026,27 +1026,19 @@ (defun org-capture-set-target-location (&optional target) ((or (org-capture-get :time-prompt) (equal current-prefix-arg 1)) ;; Prompt for date. - (let* ((org-end-time-was-given nil) + (let* ((org-time-was-given nil) + (org-end-time-was-given nil) (prompt-time (org-read-date nil t nil "Date for tree entry:"))) (org-capture-put :default-time - (cond ((and (or (not (boundp 'org-time-was-given)) - (not org-time-was-given)) + (cond ((and (or (not org-time-was-given)) (not (= (time-to-days prompt-time) (org-today)))) ;; Use 00:00 when no time is given for another ;; date than today? (apply #'encode-time 0 0 org-extend-today-until (cl-cdddr (decode-time prompt-time)))) - ((string-match "\\([^ ]+\\)-[^ ]+[ ]+\\(.*\\)" - org-read-date-final-answer) - ;; Replace any time range by its start. - (apply #'encode-time - (org-read-date-analyze - (replace-match "\\1 \\2" nil nil - org-read-date-final-answer) - prompt-time (decode-time prompt-time)))) (t prompt-time))) (time-to-days prompt-time))) (t --8<---------------cut here---------------end--------------->8--- > However, the way the code is intended to work doesn't seem right to me, > because it simply throws away time range information at the time prompt. > If you enter a time range like "13:00-14:00" at the time prompt, you > will get a timestamp with "13:00" for the time when the %T template is > expanded. (This is because org-capture-set-target-location uses the > beginning of the entered time range to set :default-time, which must be > an encoded time value, and there is no obvious way to set a time range.) > This is a surprising contrast with the behavior of %^T, which preserves > the time range information in the timestamp entered. But fixing this > will be a larger change and possibly requires some discussion. Hmm, I haven't wrapped my head around that enough to know what I think, but perhaps the thread I pointed to above is relevant, at least for historical context. > Subject: [PATCH] org-capture: fix expansion of %T when capturing to a datetree > > * org-capture.el (org-capture-set-target-location): Use a narrower > regular expression to replace a time range by its start time when > setting :default-time, so that dates do not get mangled. > > TINYCHANGE > --- > lisp/org-capture.el | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/lisp/org-capture.el b/lisp/org-capture.el > index f40f2b335..df0eccdbb 100644 > --- a/lisp/org-capture.el > +++ b/lisp/org-capture.el > @@ -1038,12 +1038,12 @@ Store them in the capture property list." > (apply #'encode-time 0 0 > org-extend-today-until > (cl-cdddr (decode-time prompt-time)))) > - ((string-match "\\([^ ]+\\)-[^ ]+[ ]+\\(.*\\)" > + ((string-match "\\(--?\\([012]?[0-9]\\)\\(\\(:[0-5][0-9]\\)\\|\\(am\\|AM\\|pm\\|PM\\)\\>\\)\\)\\(.*\\)" > org-read-date-final-answer) Judging by org-plain-time-of-day-regexp, mixed case (e.g. "Pm") is allowed too. Also, you could make it so that the reader doesn't need to count regexp groups by dropping the trailing group and then just using an empty string with replace-match. Non-capturing groups could also be used, though that'd make an already long regexp longer. > ;; Replace any time range by its start. > (apply #'encode-time > (org-read-date-analyze > - (replace-match "\\1 \\2" nil nil > + (replace-match "\\6" nil nil > org-read-date-final-answer) > prompt-time (decode-time prompt-time)))) > (t prompt-time))) > -- > 2.20.1