Emacs : GNU Emacs 30.2 (build 1, aarch64-apple-darwin23.2.0, NS appkit-2487.30 Version 14.2 (Build 23C64)) of 2025-12-05 Package: Org mode version 9.7.11 (release_9.7.11 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)
Subject: Inactive timestamp with zero-padded month/day treated as agenda-active Org mode version: 9.7.11 (Please attach the output of M-x org-submit-bug-report, which fills in Emacs version, org-mode version, and relevant variable state automatically.) ** Summary An inactive timestamp [YYYY-MM-DD] with zero-padded (two-digit) month and day is fontified and behaves as though it were an active timestamp (clicking it opens the day agenda), while the same date written with unpadded (single-digit) month/day, [YYYY-M-D], is correctly treated as inactive (no agenda link). Su Per the manual (Timestamps, Creating Timestamps), square-bracket timestamps should never trigger agenda inclusion regardless of the digit width of the month/day fields. This currently only holds for the unpadded form. ** Steps to reproduce 1. Open a new, empty buffer, M-x org-mode. 2. Type the following two lines exactly: [2026-9-12] [2026-09-12] 3. Observe the fontification: the two timestamps are colored differently. 4. Click on (or put point on and press C-c C-o) each timestamp. ** Expected behavior Neither timestamp should open the day agenda. Both are square-bracket (inactive) timestamps; only the digit-padding of month/day differs. Per the manual, this should have no bearing on active/inactive status. ** Actual behavior - [2026-9-12] (unpadded) -- renders as plain text, no agenda link. This is correct. - [2026-09-12] (zero-padded) -- renders in a distinct color/face and clicking it opens the day agenda for 2026-09-12. This appears to be the same treatment an active <2026-09-12> timestamp would receive. ** Additional notes - Reproduces in a fresh, minimal two-line buffer with no prior editing history, ruling out stale text properties or jit-lock artifacts as the cause. - Originally noticed in a table of inactive timestamps generated in bulk (via C-c | table conversion from a plain list of date strings), where entries with unpadded month/day were consistently rendered and behaved differently from entries with zero-padded month/day, in a pattern that correlated exactly with this minimal reproduction. - Suspect this is either (a) the inactive-timestamp fontification/ agenda-scan regexp accepting a stricter [zero-padded] pattern that incidentally overlaps with logic intended for active timestamps, or (b) the reverse -- a regexp intended to match inactive timestamps failing to match the zero-padded form and falling through to a more permissive/active-timestamp-adjacent match. Have not inspected org-ts-regexp0 / org-ts-regexp-both directly to confirm which.
