Live Session Infrastructure: Time Zones Are the Real Adversary
Streaming provider integration, storing schedules, attendance, and recordings — plus the mistake every booking system makes.
Most failures in live session systems are not about streaming, they are about time. A session shown to a learner an hour off, or that shifted when daylight saving changed, or booked into the past. Those are modelling bugs, not integration bugs.
Store time twice
Store the instant in UTC, **and** store the named time zone the schedule was set in — "Asia/Riyadh", not "+03:00". A fixed offset loses its meaning the moment the rules change; the named zone preserves the organiser's intent: "10am my time" stays 10am.
A recurring session is not repeated rows
- Store the recurrence rule once, not a hundred pre-generated rows.
- Materialize occurrences on demand, persisting only the ones that were edited or cancelled.
- Compute recurrence in the organiser's named zone, or sessions drift by an hour at daylight saving.
- Decide explicitly: does an edit change one occurrence or all following ones? That question will be asked.
Integrating the streaming provider
Do not make creating the provider's meeting part of saving the session. The provider can be slow or down, and that must not stop an instructor scheduling a lesson. Create the session on your side first, then create the meeting asynchronously with retries, and show link status clearly. Store the provider's meeting id so you can update and cancel later.
Any operation that depends on a third party and must succeed immediately is an outage scheduled for a date you do not choose.
Attendance: define it before measuring it
Is attendance joining? Staying 20 minutes? Half the duration? It determines certificates, reports, and follow-up. Pull attendance records from the provider after the session ends rather than during, and compute attendance with a rule configurable per course — you will be asked for it.
Recordings have a lifecycle
A recording appears minutes to hours later, so treat it as an asynchronous process with visible state: processing, ready, failed. Decide the retention policy early — session recordings fill storage faster than anything else, and deleting them on an announced schedule is easier than deleting them after a complaint.
The named zone you should be storing comes from the IANA Time Zone Database, which changes several times a year — treat it as data, not as constants. And the recurrence rules you do not need to invent are specified in RFC 5545, iCalendar.
If you are building a scheduling system, the time model is the first thing to review because it is the hardest to fix later. Talk to us.
FAQ
Show the learner's time zone or the organiser's?
The learner's, with the zone stated explicitly. Ambiguity here means learners miss sessions.
How do I prevent double booking?
Check for conflicts at write time with a lock on the instructor resource, not with a pre-check another booking can slip past.
Should I build streaming myself?
No. Live streaming is among the hardest things to operate; integrating a mature provider is the right call in nearly every case.