What are the best practices for using use cases to model system behavior that is executed periodically based on a schedule (rather than executed as a direct result of an explicit user interaction)?
If 'time' is modeled as an actor, what are accepted approaches to describing how time is used to trigger the use case (e.g. whether the period is configurable, valid ranges, etc.)?
It might be better to consider the actor who caused a particular task to be scheduled as still being the actor when the task actually starts:
and add a note indicating that the latter occurs overnight.
Now that I write this, I don't think time is an issue in the use case. At this level, what's important is what happens and which actors are involved. When it happens is no more important at this stage than how.
Is the scheduling part of your system or external to it?
If the schedule is external, then I treat it as the actor. We then don't see time.
If scheduling is the system's responsibility, then I think it's may be helpful to think of time as an actor "tolling the bell", or in other words providing input. Enumerating time's responsibilities helps in the design of the schedule. However there will also be other actors who actually set the schedule. Separate time, from schedule.
Time is never a primary actor, after all, time doesn't receive something of value from the system when a use case is instantiated?
I think you are confusing your implementation decision with the business requirement that your implementation decision was chosen realize.
If you could provide an high-level description of what is being done periodically and why, I could elaborate.