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 <yantar92@gmail.com>]

Ihor Radchenko <yantar92@gmail.com> 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?

Best,
Ihor