The documentation for not-after? recites:

Like before?, except returns true if the inputs are equal.

The documentation for before? states:

Returns true if time entities are ordered from the earliest to the latest (same semantics as <), otherwise false.

This seems to imply that not-after? should be semantically equivalent to <=, but it is not when invoked like:

If semantically equivalent, this s-expression should have returned true. Note that before? is, in fact, semantically equivalent to <:

This issue seems to be a consequence of how not-after? is defined as the complement of after?, as the latter is consistent with the behavior of >:

The same applies to not-before?.

Not sure if this is intended behavior or not, but I found it rather confusing. In addition, when one of these functions is apply-ed, the client code is forced to explicitly check for the arity 1 case and override the result of the evaluation, like so:

(if (> (count coll) 1)
     (apply not-after? coll)
     true)