Skip to content

What's New?

Summary of changes:

  • Create events using starts_at and ends_at instead of date.
  • Events are no longer restricted to a single day; they can span multiple days, up to a maximum duration of one year.
  • Creating events by date remains available for backwards compatibility.
  • Events now use a UUID as event_id, replacing the old <tenant:scope:facility>_<date> convention.

Details:

  • New fields: starts_at and ends_at are ISO 8601 datetimes without timezone (naive). The facility’s timezone is applied server-side, and values are stored internally in UTC.
  • Validation: ends_at must be after starts_at; duration must not exceed 365 days.
  • Backwards compatibility: if date is provided, the API will infer starts_at and ends_at for same-day events; consider migrating to explicit datetimes.
  • Identifiers: event_id is now a UUID (e.g., d92deefb-764e-462c-a0ef-fe9598b6572e). Legacy IDs like tenant:scope:facility_yyyy-mm-dd are deprecated and only accepted for existing records.

Migration guidance:

  • Prefer sending starts_at and ends_at on event creation and updates.
  • If existing clients use date, plan a phased migration and validate that generated ranges meet your business rules.
  • Update any filters or UI components that assumed single-day events to display and handle ranges.

Notes:

  • Endpoint behavior and response schemas remain otherwise unchanged.
  • Client input should omit timezone offsets in starts_at/ends_at. The system resolves to the facility timezone and persists as UTC.
  • When displaying events to users, convert UTC back to the relevant facility timezone to avoid off-by-one-day or DST issues.