# Event time (/docs/event-time)



After Hours starts at **19:00 in Sydney on 7 November 2026**. That corresponds
to **08:00 UTC**. Store the timezone of the event alongside the instant so your
product can display the intended venue time.

<DocsFlow label="One event time, with its context" steps="[&#x22;19:00 Sydney&#x22;, &#x22;Australia/Sydney&#x22;, &#x22;08:00 UTC&#x22;]" />

## Send an instant and a timezone [#send-an-instant-and-a-timezone]

The SDK accepts `startAt` and `endAt` with `utc` and `timezone` fields. Raw HTTP
uses `start_at` and `end_at`. Do not send the returned `local` field as input.

```ts title="event-time.ts · server only"
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;
```

The response includes the local representation:

```json title="Response excerpt · start_at"
{
  "utc": "2026-11-07T08:00:00Z",
  "timezone": "Australia/Sydney",
  "local": "2026-11-07T19:00:00"
}
```

## Collect local time carefully [#collect-local-time-carefully]

A datetime input without a timezone does not identify an instant. When your
product collects a venue-local time, also collect the IANA timezone and resolve
that pair to UTC before calling the API. The dashboard provides this conversion
when you configure an event there.

Daylight-saving transitions can make a local time ambiguous or nonexistent.
Ask the organiser to resolve that choice; do not silently interpret it in the
browser’s timezone or append `Z` to a local datetime.

## Display the event’s intended time [#display-the-events-intended-time]

Use the returned `local` value for the venue-local representation, or format
`utc` with `timezone` explicitly. Label any attendee-local conversion so people
know which timezone they are seeing.

See the [API reference](/docs/api-reference) for the complete event schema.