Synthetic teaching example for a website delivery brief. Not a client result, live account test or certification.
“2:30 in Melbourne” can be an incomplete booking instruction
A booking website that stores a local date and clock time without the timezone and resolved instant can create an ambiguous appointment around daylight saving. For a business commissioning a new booking flow, ask what happens at both clock changes, not just on a normal weekday. The example concerns software acceptance, not business opening hours.
| Melbourne input | UTC candidates in the fixture | Decision |
|---|---|---|
| 4 October 2026, 02:30 | None | MISSING_LOCAL_TIME |
| 5 April 2026, 02:30 | 4 April 15:30Z and 16:30Z | AMBIGUOUS_REQUIRE_CHOICE |
| 5 October 2026, 09:00 | 4 October 22:00Z | ONE_MATCH |
Use the filled example
Download the finite Node checker and filled input. Run with Node 24 or newer; no account, API or network is used.
node checks.mjs melbourne-booking-dst melbourne-booking-dst.jsonThe checker tries the two relevant +10 and +11 offsets, then round-trips each candidate through the runtime’s Australia/Melbourne timezone data. It returns zero, two and one matching instants for the supplied inputs. Record the Node runtime and timezone-data environment with the test; this deliberately small function is not a general global-timezone library.
What should the customer and operator see?
For the missing time, the interface should request a valid choice rather than silently moving the booking. For the repeated time, the booking contract needs an explicit disambiguation policy and a confirmation that makes the resolved instant clear to both sides. Store an instant together with the named timezone and retain the original selection where appropriate.
Also test notification display and calendar export against the same resolved instant. A customer selecting a different timezone must not alter the merchant’s slot without a clear conversion. Actual provider APIs and business availability remain separate checks; this resource neither reserves nor sends an appointment.
Only the named 2026 Melbourne examples are covered. Different jurisdictions, historic rule changes, leap behaviour or unsupported runtimes need an established timezone implementation and their own tests, not an extension of these two offsets by guesswork.
Primary facts and limits
Reserve Bank of Australia: daylight saving dates: Lists Victoria’s 5 April 2026 clock-back and 4 October 2026 clock-forward transitions.
Sources reviewed 15 October 2026. The supplied input and acceptance rules are original teaching design; check current platform versions and your actual delivery contract before implementation.