Skip to main content
Semantic time lets you define named time periods (“morning”, “lunch_rush”, “closing”) that map to concrete hours. The same name can mean different times on different days.

Why semantic time?

Businesses think in terms like “we need 3 servers during lunch rush”, not “we need 3 servers from 11:00 to 14:00”. Semantic time bridges that gap:
  • Define periods once with human-readable names
  • Reference them in coverage requirements
  • Let the system resolve to concrete hours based on the day

Defining semantic times

Use defineSemanticTimes to create a context with named periods:

Variants by day

The same semantic time can have different hours depending on the day of week:
On Saturday, “business_hours” means 10:00–15:00. Every other day, it means 9:00–17:00.

Creating coverage from semantic times

Use times.coverage() to define coverage in semantic terms, then times.resolve() to produce concrete coverage requirements:
The resolver expands semantic coverage into one concrete CoverageRequirement per day, applying any day-specific variants automatically.