I wasn't altogether certain that it could never be nil, and my eyes seem
to have skipped over the expression you called out so I missed that case
in my testing. I have reworked the patch as you suggest. Now the
behavior should be entirely unchanged except in the `untilnow' case
where we use the new date, no extra nils.

Revised patch attached.

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Jack Henahan <jhenahan@me.com> writes:
>
>> 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
>
> That's not true. Currently, `org-clock-special-range' never returns
> a nil start time. This is where I don't understand your patch:
>
>> -		    (`untilnow org-clock--oldest-date)
>> +		    (`untilnow nil)
>>  		    (_ (encode-time 0 m h d month y))))
>>  	   (end (pcase key
>>  		  (`interactive (org-read-date nil t nil "Range end? "))
>> @@ -2283,8 +2251,12 @@ have priority."
>>  	      (`interactive "(Range interactively set)")
>>  	      (`untilnow "now"))))
>>        (if (not as-strings) (list start end text)
>                                     ^^^^^
>                               this can now be nil
>> -	(let ((f (cdr org-time-stamp-formats)))
>> -	  (list (format-time-string f start)
>> +	(let ((f (cdr org-time-stamp-formats))
>> +              (safe-start
>> +	       (if (not start)
>> +		   (encode-time 0 0 0 0 0 -50000)
>> +		 start)))
>> +	  (list (format-time-string f safe-start)
>>  		(format-time-string f end)
>>  		text))))))
>
> Why not replacing `org-clock--oldest-date' with (encode-time
> 0 0 0 0 0 -50000) in the let binding above?
>
> Regards,