Why event time isn’t just a UTC timestamp

After Hours starts at 19:00 in Sydney on 7 November 2026. That is 08:00 UTC, but a guest needs to see the venue’s schedule. Keeping the timezone alongside the instant lets your product display both without assuming the organiser and attendee live in the same place.

Collect the local date and time together with an IANA timezone. Resolve that pair to an instant on your backend, or use the dashboard’s event editor. Appending “Z” to a local datetime does not convert it to UTC; it changes what the value means.

Eventlayer accepts an instant and timezone. The SDK uses startAt; raw HTTP uses start_at. The local representation is returned by the API, not accepted as an input field.

const { data: event, error } = await eventlayer.events.create({
  name: "After Hours",
  startAt: {
    utc: "2026-11-07T08:00:00Z",
    timezone: "Australia/Sydney",
  },
});
if (error) throw error;

Daylight-saving transitions can create times that occur twice or not at all. Your local-time input should ask the organiser to resolve that choice before sending the API an instant. Do not silently use the browser’s timezone to make the decision.

Use the returned local value for venue time, or format the UTC instant with its timezone explicitly. Background jobs can use UTC for reminders and comparisons. If you also show an attendee’s local time, label both so “19:00” never has to explain itself.