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". 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. 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. -- Best, Richard