Despite a "yes" could be defended, you shall not consider time, nor even cron, as primary actor. Using cron is only an implementation detail to achieve periodical action.
Some more details
In theory, time is not an actor
Actors are not part of the hexagonal architecture, but belong use-cases of the system (link to Alistair's archived original article is in the references of wikipedia):
This is related to the idea from use cases of “primary actors” and
“secondary actors”. A ‘’primary actor’’ is an actor that drives the
These actors interact with the system to achieve their goal. I'm not a qualified philosopher, but I think that time is a dimension and has no goal. And if it would have, it would certainly not need our systems.
In a use-case analysis,
cron could be seen as a separate system, that uses your system to achieve its own goals, and could thus qualify as primary actor. But does your system bring any value to cron and interact with it?
In practice, cron is not an actor but an implementation detail
Although we could argue whether theoretically cron could be an actor, in reality
cron is just an implementation detail. Cron does not need your system, but your system needs cron to fulfil a periodicity requirement.
The right way to handle this implementation detail is, as you say, to view cron + bash script as an adapter. Another valid implementation could be to let your system in the background and monitor itself the OS timer. For the human observer, this would make no difference and would address exactly the same requirements.
Note: Timing considerations are usually not relevant for use-case and actor identification. Time is specific to the sequence of actions; so you would show it in activity diagrams with timing events, or in timing diagrams (although these seem overkill here).
But what was the problem in the first place?
Your question is meant to help you design your architecture. Let's read Alistair's article till the end, to see how actors are used :
the asymmetry matches Ivar Jacobson’s primary and secondary actors concept, and affects how the Configurable Dependency is implemented.
In the case of primary actor ports, the macro constructor will pass to the UI, test framework, or driver the handle for the app and say, “Go talk to that”. The primary actor will call into the app, and the app will probably never know who called it. (That is normal for recipients of a call).
In your special case, whether cron is or not an actor would not really influence your design. The macro-constructor would probably be the same.
The question of the primary actor is a different one:
- Isn't there some interaction between your system and some humans or other system? Your app may talk with the standard input/output (redirected from somewhere), may use files (provided by real actors, users or other systems), may interact with real actors (directly with user or remote systems, or indirectly via log/output files).
- How should the construction process be these interactions? For example, how would the construction be different for running tests and for the productive use?