From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id oBZgFmxCOmJO5gAAgWs5BA (envelope-from ) for ; Tue, 22 Mar 2022 22:41:00 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id SOXmDmxCOmJRRgAAG6o9tA (envelope-from ) for ; Tue, 22 Mar 2022 22:41:00 +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 E3DBFA704 for ; Tue, 22 Mar 2022 22:40:59 +0100 (CET) Received: from localhost ([::1]:47650 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nWmFO-0001kp-Hy for larch@yhetil.org; Tue, 22 Mar 2022 17:40:58 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43908) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nWmEz-0001kR-3V for emacs-orgmode@gnu.org; Tue, 22 Mar 2022 17:40:33 -0400 Received: from [2607:f8b0:4864:20::1029] (port=56295 helo=mail-pj1-x1029.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nWmEx-0001Th-Cr for emacs-orgmode@gnu.org; Tue, 22 Mar 2022 17:40:32 -0400 Received: by mail-pj1-x1029.google.com with SMTP id jx9so2893194pjb.5 for ; Tue, 22 Mar 2022 14:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version; bh=+YqLABhVxevfNJVVZ3G128SCxLESS24HxyX/5f32Tu0=; b=C/3dD85UlmtMCc8y8mSyIK2eDGa1ET+P0CARTwjKWJBLZ0p5TbGFLgQ9UB+4nWeWq6 jgWpVIO4xb1B4lzTBssye7a6N57hm6JiKOIFAA2aZAKr+MbYQGB63d+QudKMbW6OI9wR 8sOA1BI1lqkpENHweDvdt4i0zm3Blcnod0W2KLhYjZ8bwVNQvvF2zZ8+n1EUEfLTWNaz lb6u42D3HAwqdWZY/UsMKZGH/qqC0sW/WrYrrNdHbMoG213uZ2BHd3S04oecDxcprwY2 qKKxVq+6nYrwdWyRI2ibFnhOQGex2frLpcfPSo6fce7Am8l+EORMhQJVvvFOl7/7xaKR QlIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version; bh=+YqLABhVxevfNJVVZ3G128SCxLESS24HxyX/5f32Tu0=; b=1+m9cETJwCROpOm2lmQISu+xSL0875/0llsrF+gwuj6WtDPehj+KdTpAnk9fskRhR8 Y01FU0yEk/KnN1I/iDlh7fi5f2oN/rV0VUjDtH1Hu0O62/seb9K+NQumDmBeDaNhMooo 8vvVOFrBIfLX79/GanY8jq2hb709eyRqC5ITIWkLt/A7dOAG4gae/6xbGC9P5SIhfwG+ 3Swf1Wg8hfJBtSNiDzrrFs2fyvT0BKn0dTOSgix+Uv9uEb4VNbb12vmmtwOyUNPQp2cK jG7uchjXh3S/bQF72KSLBswJsQd+Cwzsp2aetE1W3avFBSeIospqbLw20TnzJ3YGYeRc 9llg== X-Gm-Message-State: AOAM533TFxxGa922LwUo/mcajD78giHq0JAwnrKBgm3udP8ljTGDPI4F cVDseITNPTv3VoO4qtJxcn8KpMavKjvcpA== X-Google-Smtp-Source: ABdhPJzqxBUKfhe+FJCE2ofzaulPQhAVcUJH6ALzkym0hO+8rXt+s1bInCWRI7qecqbNebHLV40FNg== X-Received: by 2002:a17:903:32ce:b0:154:4a39:294d with SMTP id i14-20020a17090332ce00b001544a39294dmr14732286plr.48.1647985229502; Tue, 22 Mar 2022 14:40:29 -0700 (PDT) Received: from dingbat (220-235-26-154.dyn.iinet.net.au. [220.235.26.154]) by smtp.gmail.com with ESMTPSA id g3-20020a056a001a0300b004fa65cbbf4esm17726360pfv.63.2022.03.22.14.40.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Mar 2022 14:40:29 -0700 (PDT) References: <87v8wje4nd.fsf@localhost> <066001d83d3c$7b463380$71d29a80$@tomdavey.com> <87tubqmi94.fsf@localhost> <87r16umhnj.fsf@localhost> User-agent: mu4e 1.7.10; emacs 28.0.92 From: Tim Cross To: Ihor Radchenko 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: Wed, 23 Mar 2022 08:10:05 +1100 In-reply-to: <87r16umhnj.fsf@localhost> Message-ID: <87pmmdsm2f.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::1029 (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::1029; envelope-from=theophilusx@gmail.com; helo=mail-pj1-x1029.google.com X-Spam_score_int: -6 X-Spam_score: -0.7 X-Spam_bar: / X-Spam_report: (-0.7 / 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, FREEMAIL_FROM=0.001, PDS_HP_HELO_NORDNS=0.659, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, 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: , Cc: Ignacio Casso , emacs-orgmode@gnu.org, tom@tomdavey.com, Nicolas Goaziou 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=1647985260; h=from:from:sender:sender: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:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=+YqLABhVxevfNJVVZ3G128SCxLESS24HxyX/5f32Tu0=; b=GDKbvd2qZD1CWnDfoewpzqH+FFBndE+iR+3Aca74gm1HA3IcQIR6MYA2xojGwZ3SzoX5Jm zDBNVLgkEvLafbsidq87ODr8vG1K31W5OB2lcrHc2ctHtEZ6KMTDWhO0/SFhScQ0lqA0C7 X1vCiKMzOuvF6Dnr6a9FNCk2ozKj8l/V87tUYHH1rz4OiaBukg9w1OCLvU73mMase7wWmh ylGdorPr1EHqe1K/xfewzdE1+I8sJbQFnvnxpwCgN1XZGhcJLB8n/druAFa93ND5iOfGhP Dd99yV8N7Ga6mBifT8Hw6W9tPNSTN/4LdxBAyWfeSutGACdHJIWMktjSGS4kHg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1647985260; a=rsa-sha256; cv=none; b=Wxfpm/XmKMW0ZnvoBLnhgz5OKzKXPmAPCrLdIgYi3Uz/BYxBMWPIdw7BB1N7XCegq4cE7L /8SSWbRuowAu8P4YLD/WEOydJ8GKrIWcm0TbhcAcmG9frKeO0tE802NmcZoAlkxwY/IKvm SzMNelQcF7A0f1SA+iCyTA5SEekmCL5pjjq8/IAV79apmcvvNW4+pEFmik1u4g1Hw5VdaD Q8OFtNZxHEGLcrVZ2bGQ7+HOCIIOnxFEYQJSX6+WCHF2soHPqXR2XMu1vxtqubJMCF3iJq fHzkM2YGLRfkV+mdWC41Dl89gqf3VwfD5q73aF/yQIDN5v1QJJavVnmnQYz09w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b="C/3dD85U"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=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: 7.15 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b="C/3dD85U"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=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: E3DBFA704 X-Spam-Score: 7.15 X-Migadu-Scanner: scn0.migadu.com X-TUID: X715YE1SXUh5 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).