Time
AEL, the Agent Engineering Language, will keep two kinds of time apart, so that a clock change can never shorten a timeout or make a duration negative.
Status
Planned for AEL Beta 0.0.1. AEL is not available yet.
| Kind | Moves | Use it for |
|---|---|---|
| Monotonic time | Only forward, from a point of its own. | Durations, deadlines, timeouts and timers. |
| Wall-clock time | With the calendar, and can jump when the clock is set. | Timestamps in logs and records, and calendar schedules. |
A duration will always be measured with monotonic time. Two wall-clock times will never be subtracted to find how long something took.
Reading the time
Reading a clock will be an effect, and the compiler will track it like any other: a function that reads the time will say so through everything that calls it, and no helper will be able to hide it. See Effects and capabilities.
Durations
- Durations will be whole numbers with checked arithmetic. They will never be negative, and an overflow will be reported like any other.
- You will be able to express a duration in nanoseconds, but that will not promise nanosecond accuracy: the resolution will depend on the target's clock.
- Time measured on one machine will be compared only with time from the same clock. Comparing timestamps from different devices will need a stated bound on how far their clocks may differ.
Deadlines and timeouts
- Every request and every call to a model, a service or another program will have a finite deadline.
- Child work will inherit the earliest deadline of the work that started it. A retry or a restart will never extend a deadline.
- When a deadline is reached, the work will fail at that point. Nothing will wait past it, including the delay before a retry.
- Retries, output repair, timeouts and cancellation will draw on one shared budget, so nested retries cannot multiply cost. See Budgets, retries and validation.
Timers
Timers will wake a waiting handler after a duration. Concurrency describes how they fit the scheduling model.
- Timers will measure monotonic time, and keep working when a hardware counter wraps around to zero.
- You will be able to cancel a timer. A timer that was cancelled or reused will never be able to wake the wait it used to belong to.
- Timers that expire at the same moment will run in a defined order.
- On a microcontroller, the number of timers will be fixed when you build. Running out of timers will be a typed result, not a crash.
Delays on a board
A microcontroller program will read a monotonic clock and use bounded delays and polling, as part of the hardware access that also covers GPIO, UART and interrupts.
- A delay or a poll that blocks will say so, and the compiler will track it: a real-time path will not be able to call it.
- Waiting on a timer will let other handlers run; a delay that blocks will not. Prefer timers for anything longer than a short pause.
Schedules
Agents will be able to start on a schedule, on a poll or on an event. Scheduled triggers will have:
- intervals, or calendar schedules in a named time zone, with defined behaviour across daylight-saving changes;
- a missed-run policy, with a limit on how many missed runs are caught up;
- an overlap policy for a run that starts while the last one is still going;
- a maximum number of concurrent runs, and pause and resume.
Schedules will survive restarts. Workflows describes triggers.
Time in the time and token summary
The elapsed time of a run, reported by default when it ends, will be measured with monotonic time. You will choose the unit it is shown in, or turn it off; see Console and logging.
Testing code that uses time
Tests will run time-dependent code against a controlled clock that advances only when the test says so: timeouts, schedules across time-zone changes and timer wraparound can be tested without waiting. See Testing.
Not yet described
The names of the time and duration types and of the operations on them will be published when the library is final. Date and calendar arithmetic beyond schedules is not described in the preview.