From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id MNoVEi1ZOmJibgEAgWs5BA (envelope-from ) for ; Wed, 23 Mar 2022 00:18:05 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id mMfNDi1ZOmIWfAAAauVa8A (envelope-from ) for ; Wed, 23 Mar 2022 00:18:05 +0100 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 317A326884 for ; Wed, 23 Mar 2022 00:18:04 +0100 (CET) Received: from localhost ([::1]:39412 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nWnlL-0005tR-2e for larch@yhetil.org; Tue, 22 Mar 2022 19:18:03 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38136) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nWnkQ-0005qk-EV for emacs-orgmode@gnu.org; Tue, 22 Mar 2022 19:17:10 -0400 Received: from walmailout06.yourhostingaccount.com ([65.254.253.54]:56825) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nWnkO-00062W-Ij for emacs-orgmode@gnu.org; Tue, 22 Mar 2022 19:17:06 -0400 Received: from mailscan07.yourhostingaccount.com ([10.1.15.7] helo=walmailscan07.yourhostingaccount.com) by walmailout06.yourhostingaccount.com with esmtp (Exim) id 1nWnkM-0002Zg-OI for emacs-orgmode@gnu.org; Tue, 22 Mar 2022 19:17:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tomdavey.com; s=dkim; h=Sender:Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From:Reply-To: Cc:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Yy9CSq5rhp0BBDSyGwafxQi3FuZYXXjLZAE2fp63bA8=; b=zZA5N8HHLU06hM5dGC2OHZOprV TAQoh1a5dIix6L+0BHBNNqbot7jrOXJHUpR3mbD5yuSyBbMyRgVqCwmXq9/y6ZsZkngR5LxoBVVjc qeYpURbso4kDavUZ1YFD/0sNTJiIGww/rooTLfwsU7NFCqQa6CeJPIdwJutLqOjpL9sMM8ChVyc65 sUlI2qnUyZspXPqH345fxoLZOFqfi9FBDcsBKKCOWWQcIHjoN6CnWnLef9chKLInp7UuBH0xKilwm 33+wdGRHGVc+D9KKJWJTBUSe3Ny/EvHRte2how+q8vjoMGgb6ud+D4s2OeKSCM+qbDFHfcVZLeVnx 6/fA3E9w==; Received: from [10.114.3.21] (helo=walimpout01) by walmailscan07.yourhostingaccount.com with esmtp (Exim) id 1nWnkM-0000gD-Fo for emacs-orgmode@gnu.org; Tue, 22 Mar 2022 19:17:02 -0400 Received: from walauthsmtp55.yourhostingaccount.com ([10.1.18.55]) by walimpout01 with id 9bGz270021BHSKu01bH2fl; Tue, 22 Mar 2022 19:17:02 -0400 X-Authority-Analysis: v=2.3 cv=Q5RJH7+a c=1 sm=1 tr=0 a=mlU0NoEniGbFwgVt2QZi2A==:117 a=zuBDUjl1ZKkaZ1e1JP5yeA==:17 a=TytkCCWg1XC4WIkd:21 a=kj9zAlcOel0A:10 a=o8Y5sQTvuykA:10 a=BJfXAp5dUnUA:10 a=6JfXMdr6AAAA:8 a=mDV3o1hIAAAA:8 a=pGLkceISAAAA:8 a=69EAbJreAAAA:8 a=UChi4ALMP8pvDDBke4YA:9 a=CjuIK1q_8ugA:10 a=K9YFMUmg2nkA:10 a=WABqsgMylfao6gabR53I:22 a=qxdsFW7UbgJMkt82kd0D:22 a=TsfbUbXGka_IpY0nsRw-:22 a=_FVE-zBwftR9WsbkzFJk:22 Received: from cpe-74-73-105-65.nyc.res.rr.com ([74.73.105.65]:55355 helo=Penny) by walauthsmtp55.yourhostingaccount.com with esmtpa (Exim) id 1nWnkI-0003bv-W0 for emacs-orgmode@gnu.org; Tue, 22 Mar 2022 19:16:59 -0400 From: "Tom Davey" To: References: <87v8wje4nd.fsf@localhost> <066001d83d3c$7b463380$71d29a80$@tomdavey.com> <87tubqmi94.fsf@localhost> <87r16umhnj.fsf@localhost> <87pmmdsm2f.fsf@gmail.com> In-Reply-To: <87pmmdsm2f.fsf@gmail.com> Subject: RE: Timestamp parsing inside node properties and other contexts out of org-element-object-restrictions (was: [BUG] Agenda no longer works for timestamps inside properties drawer [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]) Date: Tue, 22 Mar 2022 19:16:58 -0400 Message-ID: <075801d83e42$eea0aa20$cbe1fe60$@tomdavey.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJ3HNglNZJhNnwc8Y7Nepy+BoBfkQMVdBpPAjDlchsBrGWl/wDw9IjmAtlFdrACrv6UOasi3d8g Content-Language: en-us X-EN-UserInfo: 52ba5adf417010193fa3ef08325f2c21:931c98230c6409dcc37fa7e93b490c27 X-EN-AuthUser: tom@tomdavey.com X-EN-OrigIP: 74.73.105.65 X-EN-OrigHost: cpe-74-73-105-65.nyc.res.rr.com Received-SPF: pass client-ip=65.254.253.54; envelope-from=SRS0=kXn3t2=UB=tomdavey.com=tom@yourhostingaccount.com; helo=walmailout06.yourhostingaccount.com X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: tom@tomdavey.com Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1647991084; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=Yy9CSq5rhp0BBDSyGwafxQi3FuZYXXjLZAE2fp63bA8=; b=V2h9QyjovmjMCQdVrti+kFsrv9DzMrRRuWW+o9W9gzE34yK3cprQ8Gk/wmTj3RXRlRJCyx XKoLCy90Gskygny8CetvakfsPt3OIdxjEdZaJlFDmfCSqQ2jCsGLp4JbjLrxfHCmEh/Ppo 6b0+2zPBFfHIADpePvflLntDLBVqbBrprqW3JyHHxvMn8zYn1Tzt766zVzQRYZIwTfnoYm jV+E5DQt6cb7+J34KJrIfRKWMq6/ob6LrgkB2ioUsI5G0YJS5ACrZTTkTJRFaKTENNhCnV slVQ6aVQKpPgmkN8RGGMH/ckjtGSeeV5Yg6UVABoe297Uqt3jlERAEspCtdkRw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1647991084; a=rsa-sha256; cv=none; b=YCpuhXJ+21Nw09gVVtKEZS2lAxdOFYfLVxcNqqgRD9ObuloYq97BRIDhmEQdCr4Aj8sx4f C/zDfGNzR+u3XqpOYmxBU/1gZ5GTD8Bm9CC9c75W6A7Ala1wOoSAaeXohK/tzD0dzqlcdF 3dbMegbKOuogafJy9uZz/j08Bfw0LqZngijf7T7KEzEZGJn1Ltyd/BCftE0IMIyhFxIw5q 9N8wxCQMiuQNoeV5tF89MrTiKmHBI44RbjrP35WVYGAgpulCHR+CcQ8OCC5homgYD0w1Bf BYsNb+kcboDWWBSctsUPxTbJDiMbkvTeVUITSV9imDc30q9EErQrO33H2PPjtA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none ("invalid DKIM record") header.d=tomdavey.com header.s=dkim header.b=zZA5N8HH; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -2.85 Authentication-Results: aspmx1.migadu.com; dkim=none ("invalid DKIM record") header.d=tomdavey.com header.s=dkim header.b=zZA5N8HH; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 317A326884 X-Spam-Score: -2.85 X-Migadu-Scanner: scn0.migadu.com X-TUID: jFT6r/k+nKiv Hi Tim, Thanks for these thoughtful comments. I agree that the Org developers (to whom I, as a mere user, owe enormous thanks) must be wary before making changes to how timestamps are handled. This argues, I would say, for keeping what I believe was the status quo since at least Org version 9.4.4: Agenda views would display entries with active timestamps in property drawers. That has been my historical experience. Tim, has your historical experience been different? In the invoicing example you give, were the timestamps in the properties drawer active, or inactive? I have just verified with a simple test that Org version 9.4.4, which was shipped with Emacs 27.2 I believe, does display entries with an active timestamp as the value of a property in the ordinary :PROPERTIES: drawer. That's the situation I'm calling the "status quo." I'm wondering if my experience coincides with the experience of others. Here's the simple entry that will be shown on the Week/Day Agenda view in 9.4.4: * TODO Test of active timestamps :PROPERTIES: :Created: <2022-03-22 Tue 18:30> :END: And note this: adding a second active timestamp to the test entry, e.g., to accompany a SCHEDULED: keyword, results in the entry appearing on the Agenda twice, as would be expected: * TODO Test of active timestamps SCHEDULED: <2022-03-22 Tue 18:30> :PROPERTIES: :Created: <2022-03-22 Tue 18:30> :END: This second example shows why the variable org-agenda-skip-additional-timestamps-same-entry is valuable. I rarely want an entry to display twice on the same day. Tom Davey -- Tom Davey tom@tomdavey.com New York NY USA -----Original Message----- From: Emacs-orgmode On Behalf Of Tim Cross Sent: Tuesday, March 22, 2022 5:10 PM To: Ihor Radchenko Cc: Ignacio Casso ; emacs-orgmode@gnu.org; tom@tomdavey.com; Nicolas Goaziou Subject: Re: Timestamp parsing inside node properties and other contexts out of org-element-object-restrictions (was: [BUG] Agenda no longer works for timestamps inside properties drawer [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]) Ihor Radchenko writes: > Ihor Radchenko writes: > >> After further reading the source code, I figured that agenda is, in >> fact, supposed to handle timestamps inside property drawers. Optional >> arguments for org-at-timestamp-p imply that, in agenda specifically, >> timestamps inside node properties are considered timestamps despite >> they are not being parsed as timestamps by org-element. > > Even though I fixed the reported issue with agenda not showing > headings with matching timestamps inside property drawers, this > situation is revealing a big inconsistency in Org mode's handling of timestamps. > > org-at-timestamp-p usage implies that Org syntax for timestamps is not > only context-dependent, but also depends on current command! > > org-at-timestamp-p is called with non-nil argument in a number of > functions in Org: > - org-clock-timestamps-change > - org-mouse-delete-timestamp > - org-mouse-context-menu > - org-follow-timestamp-link > - org-get-repeat > - org-auto-repeat-maybe > - org-time-stamp > - ... many more in org.el > > So, depending on the current command, Org may on may not treat objects > matching org-ts-regexp-both as timestamps. > > This situation complicates syntax and makes org-element unreliable > when dealing with Org buffers. > > Should we just simply allow timestamps to be a part of node property > values? Should we _not_ treat timestamp-looking text outside their > allowed contexts (like quotes, source blocks, etc) as timestamps? > I think we have to be very wary here. I can see any changes here causing lots of breakage for people. I know for my own use case, I use timestamps a lot in property draws and various source blocks. I never want any of them showing up in my agenda. As an example, I was recently working for a company which required that you put a timestamp in both a file header and in comments. The format they used was pretty much the same as an org-mode active timestamp. I use org mode to tangle the source files I write (as well as manage my client data, such as todos, invoicing, contacts etc), so these files are searched for agenda items, but I do not want any of those timestamps causing lines in my agenda views. These timestamps are most commonly found in source and example blocks. I think the only time an org timestamp should be recognised in a source block is when that source block is an org-mode source block. I don't think they should ever be 'recognised' in example blocks. IN addition, my invoicing solution, which is based on org, uses timestamps to track invoice periods etc. None of these should ever appear in the agenda. This information is typically tracked in property draws. Unfortunately, I think org timestamps is a bit of a mess and we need to be very careful about further complicating matters. The inability to handle timezones is a major limitation IMO. The inability to handle daylight savings transitions in a consistent manner (particularly for calculation of periods, duration, etc) is often a source of errors and if you are unfortunate enough to regularly travel across different timezones, forget about using org mode to manage your schedule. I have done several deep dives into org-mode's timestamp stuff, but usually come back up gasping for air. Managing data and time data is often far more complicated than it may appear on the surface. I think we need to be extremely conservative when considering changes in this area (it is the main reason I've never managed to find a way to add time zone data - every solution I could think of was either really high on the level of breakage and frustration it would create for users or it adversely impacted the convenience/usability of org timestamps).