A useful public demo for a scheduling feature should explain which clock owns the promise. Show the intended local time, the relevant time zone, the saved event, and what another viewer sees. Then ask peers to test a specific boundary rather than judging a calendar screenshot that happens to look correct on your machine.
SaaS time zone testing has two jobs here. The product must preserve the intended scheduling meaning, and the public update must give readers enough evidence to assess that meaning. A successful demo in one browser does not establish that reminders, recurring events, and other viewers all agree.
Name the scheduling promise before testing it
Start with the user's task. âSend a reminder three hours from nowâ describes elapsed time. âSend a reminder at nine each weekday in the customer's cityâ describes a recurring local schedule. âShow this appointment in the viewer's time zoneâ describes presentation. Treat these as separate requirements.
Write the promise beside the demo. Include whether the schedule is a one-time event or a recurrence, whose time zone applies, and what happens if that setting changes. The developer and the peer reviewer should be working from the same interpretation before either starts checking a result.
This is especially important when building in public. A reply that says âthe time is wrongâ may mean the displayed hour is wrong, the saved instant is wrong, or the user expected a different zone. A clear promise turns that reply into a diagnosable observation instead of a debate about what the feature should have meant.
Keep an instant separate from a local clock reading
An instant identifies a point in time. A local clock reading needs additional context to identify when something happens. The date and time zone matter, and an offset alone is not a complete rule for future local schedules.
MDN's ZonedDateTime documentation explains the distinction between exact time and local time, including gaps and repeated local times around daylight-saving changes. It also describes cases where time-zone rules change. Those are reasons to test the product's interpretation, not just its formatting.
You do not need to adopt a particular API to communicate that distinction. MDN currently marks Temporal.ZonedDateTime as having limited browser availability. Check the compatibility and behavior of the actual library or runtime your product uses before recommending implementation details to readers.
Build a small public evidence card
For each demonstrated case, record the entered value, the chosen time zone, the scheduling promise, and the expected result. Add the app version or test environment and the observed result. Use fictional accounts and events so the artifact can be shared without exposing customers' calendars.
A useful card might describe a fictional consultation booked for a particular local date and hour in America/Toronto. The promise is one appointment at that local time, displayed appropriately to another viewer. The card should show the saved appointment after reopening, not only the value before pressing Save.
Do not put real email addresses, invitation tokens, customer names, or private calendar links in the public card. You can show a sanitized delivery record or a test inbox if it supports the question, but explain what was replaced and what evidence remains genuine. Synthetic data should be labelled as synthetic throughout the demonstration.
Follow one fictional reminder through the product
Imagine a small maintenance app that lets an operator schedule a reminder for a site manager. The operator chooses a site, enters a date and hour, and selects the site's time zone. A second person views the reminder from another location. This is a worked example, not a claim about a tested product.
First, decide whether the reminder belongs to the site or to the operator. If the intended rule is ânine in the site's local time,â changing the operator's display preference should not quietly redefine the site's schedule. Show that rule in the creation screen or supporting text so testers know what to expect.
Next, save the reminder and leave the page. Reopen the exact record and inspect the date, zone, and local hour. A correct input screen can hide a conversion or persistence error that appears only after retrieval. Keep the reopened result next to the original expectation in the evidence card.
Then view the same record as the second person. Ask them to explain when the reminder will occur and which zone the label refers to. Their answer tests communication as well as conversion. An unlabeled time that the founder understands may still be ambiguous to someone arriving from a public demo.
Finally, inspect the test reminder's actual execution or delivery record if the feature sends anything. Creation, display, and execution are distinct checkpoints. If you have only verified the first two, say that delivery remains untested. Avoid using a successful save toast as proof that the eventual notification happened correctly.
Choose boundary cases from the promise
A one-time appointment and a repeating local reminder need different cases. For the appointment, include viewers whose local dates differ at that instant. For recurrence, include occurrences on both sides of a relevant clock change. Check the expected result against the intended product rule before comparing it with the output.
Include a local time that does not exist and one that occurs twice where the selected zone has such transitions. The interface should make the product's policy understandable. It might reject an ambiguous entry or ask the user to choose. Whatever the policy is, show and test it rather than leaving the behavior accidental.
Also check what happens when a user changes the event's time zone after entering the hour. Does the product preserve the instant or the local reading? Both behaviors can serve different tasks. The requirement must say which one applies. A visible before-and-after example is more useful than claiming the app âsupports every time zone.â
Keep date-only fields separate in the review. A maintenance due date may mean a calendar day rather than an appointment instant. Converting it through a time zone without considering that meaning can produce a different displayed day. Ask the product owner which task the field represents before treating every date as a timestamp.
Ask peers to test the missing perspective
Share the evidence card with one bounded request: âCan you tell which time zone owns this reminder after reopening it?â Or ask a developer familiar with scheduling to propose the next boundary case. A general request to âtry the calendarâ gives less guidance about what would help.
Buildside's About page describes public product progress and useful founder connections. The author, Uriel Bitton, builds and runs Buildside. A founder community can supply a different perspective on this workflow; its replies do not replace a product test suite or establish correctness across all supported environments.
Separate a usability observation from a reproducible defect. If a peer cannot identify the zone, improve the label and review the task again. If an event moves after reopening, capture the sanitized inputs and environment needed to reproduce that behavior. Do not combine those findings into a vague report that time zones are broken.
Publish the result at the scope you checked
A useful follow-up names the cases, the outcome of each, and the remaining gaps. âThe saved appointment kept its intended instant in these two viewer settingsâ is narrower and more informative than âTime zones solved.â Include a failing case if it explains the next decision, without exposing private operational details.
Keep the public artifact small enough to maintain. Update its status when the test version changes, and link a follow-up rather than letting an old demo imply current behavior. Before asking anyone else to review the feature, make sure your own evidence card states what the clock is supposed to mean.
Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.
Subscribe for more stories on growing your audience by building in public.
Join us on Buildside: the social network for founders building in public.
Top comments (1)
Checking the saved event after reopening is the step I'd keep on every card, since that's where conversion bugs hide. For the "what another viewer sees" part, you can record both views in one clip: two browser contexts side by side with different time zones. Playwright's timezoneId option does this without touching the machine clock. This week is also a good boundary to test. Europe left daylight saving on 25 October and the US and Canada leave it on 1 November, so a recurring London and Toronto meeting is four hours apart for a few days instead of five. A demo that gets that week right gives readers a real reason to trust it.