Skip to content
Tickets Please

Timezone Management

Timezone Management

Events that span timezones — a virtual conference with global attendees, a traveling workshop series, or a multi-city tour — need flexible timezone handling. Tickets Please supports both site-wide and per-event timezone modes, plus optional visitor timezone detection.

Timezone Modes

Navigate to Events > Settings > Date & Time to configure the timezone mode. Two options are available:

Site-wide Mode

All events use the timezone configured in Settings > General (the core WordPress timezone setting). This is the simplest option and works well when all your events happen in a single timezone.

Event editors do not see a timezone selector. Start and end times are assumed to be in the site’s timezone.

Per-event Mode

Each event stores its own IANA timezone in the _tribe_event_timezone meta field (e.g., America/New_York, Europe/London, Asia/Tokyo). Event editors see a timezone dropdown on the event edit screen.

Use per-event mode when:

  • Your organization hosts events in multiple cities or countries.
  • You run virtual events across time zones.
  • You import events from external sources that include timezone data.

When per-event mode is active and an event does not have a timezone set, it falls back to the site timezone.

Date & Time Settings

Beyond the timezone mode, the Date & Time settings panel includes:

SettingDescriptionDefault
Timezone modesite (site-wide) or event (per-event)site
Show visitor timezoneDisplay event times in the visitor’s local timezoneNo
Week starts onFirst day of the week in month viewSite setting
Default start timePre-filled start time for new events08:00
Default end timePre-filled end time for new events17:00

Default start time and Default end time only pre-populate the time fields when creating a new event. Editing existing events does not change their stored times.

Visitor Timezone Detection

When Show visitor timezone is enabled, Tickets Please detects the visitor’s browser timezone using JavaScript and stores it in a tec_visitor_timezone cookie.

On single event pages, a secondary time display shows the event’s start and end times converted to the visitor’s local timezone. For example:

Saturday, March 14, 2026 at 2:00 PM EDT 7:00 PM in your timezone (BST)

This conversion happens client-side. The server sends the event’s canonical time and IANA timezone; JavaScript handles the localization.

How Detection Works

  1. On first page load, JavaScript calls Intl.DateTimeFormat().resolvedOptions().timeZone to get the browser’s IANA timezone.
  2. The timezone string is stored in the tec_visitor_timezone cookie (expires in 30 days).
  3. Subsequent page loads read the cookie instead of re-detecting.
  4. If the visitor’s timezone matches the event’s timezone, no secondary display is shown.

Visitors with JavaScript disabled see only the event’s canonical time. No timezone conversion occurs without JavaScript.

Working with Timezones in Code

When querying events, dates are stored in the database as Y-m-d H:i:s strings in the event’s designated timezone (or the site timezone in site-wide mode). The _tribe_event_timezone meta field tells you which timezone that string represents.

$start_date = get_post_meta( $event_id, '_tribe_event_start_date', true );
$timezone   = get_post_meta( $event_id, '_tribe_event_timezone', true );


if ( ! $timezone ) {
    $timezone = wp_timezone_string(); // Falls back to site timezone.
}


$datetime = new DateTime( $start_date, new DateTimeZone( $timezone ) );


// Convert to UTC for comparison.
$datetime->setTimezone( new DateTimeZone( 'UTC' ) );

Always use the stored timezone when creating DateTime objects from event dates. Assuming UTC or the site timezone leads to incorrect time display for per-event timezone events.

Common Questions

Can I mix site-wide and per-event modes? No. The mode applies globally. In per-event mode, events without an explicit timezone fall back to the site timezone, which gives a similar effect.

Does the visitor timezone cookie respect GDPR? The tec_visitor_timezone cookie stores only an IANA timezone string (e.g., “America/Chicago”) — no personal data. It is a functional cookie, not a tracking cookie. Include it in your cookie policy if required by your legal framework.

What IANA timezone format is used? Standard IANA/Olson timezone identifiers like America/New_York, Europe/London, Asia/Tokyo. UTC offsets like UTC+5 are not used because they do not account for daylight saving time transitions.

How does daylight saving time affect event times? IANA timezones handle DST transitions automatically. An event set to 2:00 PM America/New_York displays as EST in winter and EDT in summer. The stored time does not change — only the UTC offset shifts.

Can I change an event’s timezone after tickets are sold? Yes, but be cautious. Changing the timezone shifts when the event occurs in absolute time. Attendees who purchased tickets based on the original time are not automatically notified. Send a manual notification if you change timezones after sales begin.

What happens to imported events without timezone data? Imported events receive the site timezone if no timezone is specified in the CSV import data.

Next Steps