Schedules are expressed in terms of wall clock time, and as such have interesting behavior around daylight savings time boundaries. There are two circumstances that might affect a schedule. The first is a repeated time, which occurs when time jumps back (e.g. 2:30 may happen twice in one day). The second is a skipped time, which occurs when time jumps forward by an hour.
In both cases Schedule
does the naive thing. If the time happens twice and is
included in the schedule it is included twice. If it never happens Schedule
makes
no special attempt to artificially include it.
In_zone
: see the discussion under Zones and Tags aboveTag
: see the discussion under Zones and Tags aboveAnd
, Or
, Not
: correspond to the set operations intersection, union, and
complement.If_then_else (A, B, C)
: corresponds to (A && B) || (NOT A && C), useful for dealing
with schedules that change during certain times of the year (holidays, etc.)At
: the exact times given on every dayShift
: shifts an entire schedule forward or backwards by a known span. (e.g:Shift ((sec 3.), Secs[10]) = Secs [13]
Shift ((sec (-3.)), Secs[10]) = Secs [7]
)Between
: the contiguous range between the start and end times given on every daySecs
: the exact seconds given during every hour of every dayMins
: all seconds in the minutes given during every hour of every dayHours
: all seconds in the hours given on every dayWeekdays
: all seconds in the days given on every weekDays
: all seconds in the days given, every monthWeeks
: all seconds in the weeks given (numbered ISO 8601), every yearMonths
: all seconds in the months given, every yearOn
: all seconds in the exact dates givenBefore
: all seconds before the given boundary (inclusive or exclusive)After
: all seconds after the given boundary (inclusive or exclusive)Always
: the set of all secondsNever
: the empty set'a
indicates whether the schedule currently has an established zone.
'b
is the type of the tag used in this schedule. In many cases it can be
unspecified. See tags
for more.
Between (a, b)
is the empty set if a > b.
Items that take int list
s silently ignore int
s outside of the viable
range. E.g. Days [32]
will never occur.
| Between
:
(Inclusive_exclusive.t
* Time.Ofday.t)
* (Inclusive_exclusive.t
* Time.Ofday.t)
->
(unzoned, 'b) t
|
|||
| Always
:
('a, 'b) t
|
|||
| Never
:
('a, 'b) t
|
tags t time = `Not_included
iff not (includes t time)
. Otherwise, tags t time
= `Included lst
, where lst
includes all tags of a schedule such that includes t'
time
is true where t'
is a tagged branch of the schedule. E.g. for some t
equal
to Tag some_tag t'
, tags t time
will return some_tag
if and only if includes t'
time
returns true. For a more interesting use case, consider the per-office on-call
schedule example given in the beginning of this module. Note that a schdeule may have
no tags, and therefore, lst
can be empty.
fold_tags t ~init ~f time
is nearly behaviorally equivalent to (but more efficient
than) List.fold ~init ~f (tags t time)
, with the exception that it returns None
if
includes t time
is false. It is important that f
be pure, as its results may be
discarded.
Return a sequence of schedule changes over time that will never end.
If your schedules ends, you will continue to receive `No_change_until_at_least with increasing times forever.
The return type indicates whether includes t start_time
is true and
delivers a sequence of subsequent changes over time.
The times returned by the sequence are strictly increasing and never less
than start_time
. That is, `No_change_until_at_least x
can never be
followed by `Enter x
, only by (at least) `Enter (x + 1s)
.
if emit
is set to Transitions_and_tag_changes
then all changes in tags
will be present in the resulting sequence. Otherwise only the tags in effect
when a schedule is entered are available.
The `In_range | `Out_of_range
flag in `No_change_until_at_least
indicates whether the covered range is entirely within, or outside of the
time covered by the schedule and is only there to help with bookkeeping for
the caller. `In_range | `Out_of_range
will never disagree with what
could be inferred from the `Enter
and `Leave
events.
The sequence takes care to do only a small amount of work between each
element, so that pulling the next element of the sequence is always cheap.
This is the primary motivation behind including `No_change_until_at_least
.
The Time.t
returned by `No_change_until_at_least is guaranteed to be a reasonable
amount of time in the future (at least 1 hour).
| Transitions_and_tag_changes
:
('tag -> 'tag -> bool)
->
('tag, [
|
'tag Event.transition
|
'tag Event.tag_change
]) emit
|
in Transitions_and_tag_changes
equality for the tag type must be given