I've sent off for the FSF form so I can get that process started, and I've amended my patch according to the guidelines (attached). Jack Henahan writes: > I tested that `org-clock-display` and the clocktable work as expected > when `org-clock-display-default-range` is set to `untilnow`. > `org-clock-sum-custom` also appears to function as intended. If I'm > reading things correctly, the `untilnow` case is the only one that ought > to be affected, since it's the only one that used > `org-clock--oldest-date`. The behavior of `org-clock-special-range` > ought to be unchanged in all cases except where this symbol is > explicitly used, or the start time is nil for some other reason. > > Functionally, this means that today `org-clock-special-range` produces a > range from the current time until the current time if `start` ends up > nil for whatever reason, but with this patch it will instead produce a > range from the year -50000 until now. The -50000 hack is entirely for > the benefit of `format-time-string`, since otherwise it just gives the > current time if its second argument is nil. > >> Jack Henahan writes: >> >>> Apologies again, didn't update the commit hash properly. I swear this is >>> the last one. :| >> >> Thank you. However, I'm surprised that `org-clock-special-range' callers >> handle a nil start date. Have you tested it? >> >> If that's true, we don't need the -50000 hack at all. Returning an empty >> string might be enough.