Re: S-left / S-right with (double) prefix C-u without scheduled time (only date)

[Kyle Meyer]

Martin Rottensteiner writes:

> In my setup in org 9.4 the behaviour is like this for a scheduled date
> without scheduled time (for example SCHEDULED: <2020-10-27>:
> C-u S-left: Date changes to date before (26th)
> C-u S-right: Date does not change
> C-u C-u S-left: Date changes to date before (26th)
> C-u C-u: S-right: Date does not change

Hmph, that discrepancy between left and right is odd...

Underneath org-timestamp-change is being called with WHAT as hour or
minute.  Regardless of whether the timestamp has a time, it's doing

    (setq time
          (apply #'encode-time
                 (or (car time0) 0)
                 (+ (if (eq timestamp? 'minute) n 0) (nth 1 time0))
                 (+ (if (eq timestamp? 'hour) n 0) (nth 2 time0))
                 (+ (if (eq timestamp? 'day) n 0) (nth 3 time0))
                 (+ (if (eq timestamp? 'month) n 0) (nth 4 time0))
                 (+ (if (eq timestamp? 'year) n 0) (nth 5 time0))
                 (nthcdr 6 time0)))

So that explains why left shifts the date, as it's essentially starting
from 00:00.

> I would prefer this behaviour instead (my proposal):
> C-u S-left: Add a default time (e.g. 6:00)
> C-u S-right: Add a default time (e.g. 6:00)
> C-u C-u S-left: Add a default time (e.g. 6:00)
> C-u C-u: S-right: Add a default time (e.g. 6:00)

C-u+ is an explicit request to operate on a time part, so that sounds
sensible to me.

> Scheduled date+time Timestamps can afterwards be changed as expected with
> C-u prefix(es).

Yes, and, based on the current design, it should even work without a
prefix for successive calls.

> What I found out until now:
> ( org-schedule nil "12:00" ) adds a time 12:00 to a SCHEDULED date property.
> (if (< (length (org-entry-get nil "SCHEDULED")) 16) (print
> 'scheduled_time_missing) (print 'scheduled_time_existent))
> org-timestamp-has-time-p: could maybe better be used instead for finding
> out if time is not present.
>
> I think this would be a better default behaviour or the current behaviour
> might even be a bug.

I think the current behavior falls into the oversight/bug category,
especially given the left/right discrepancy.  Here's a minimal fix that
results in your desired behavior (assuming you don't have a preference
for any particular range of initial times).


diff --git a/lisp/org.el b/lisp/org.el
index 03df139fb..04089c6ec 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -14964,7 +14964,8 @@ (defun org-timestamp-change (n &optional what updown 
suppress-tmp-delay)
        (setq extra (match-string 1 ts))
        (when suppress-tmp-delay
          (setq extra (replace-regexp-in-string " --[0-9]+[hdwmy]" "" extra))))
-      (when (string-match "^.\\{10\\}.*?[0-9]+:[0-9][0-9]" ts)
+      (when (or (memq what '(hour minute))
+               (string-match "^.\\{10\\}.*?[0-9]+:[0-9][0-9]" ts))
        (setq with-hm t))
       (setq time0 (org-parse-time-string ts))
       (when (and updown