BOARDHERALDDocs
// platform.timezones

Timezones

A board meeting at 10:00 means 10:00 in each attendee's own zone — not a single authoritative number everyone else has to convert. Here's how BoardHerald makes that work.

The two-tier resolution

Every time BoardHerald needs to render a date or time — a meeting's start, an update's timestamp, a resolution's deadline, an audit log entry — it resolves the viewer's effective timezone in two steps:

  1. User override — if the viewer has set a timezone on their profile (Profile → Preferences), that wins.
  2. Org default — otherwise, the tenant's admin-configured default timezone applies. Default when unset is UTC.

Anywhere on the platform we display a time, it's the same resolution. So a board member in Sydney and one in Prague open the same meeting page and see times in Australia/Sydney and Europe/Prague respectively — with the correct DST offset applied for that specific date (which is non-trivial across 9-month-apart hemispheres).

IANA zones, not offsets
Timezones on BoardHerald are IANA names (e.g. Europe/Prague), not fixed UTC offsets (e.g. +01:00). This is deliberate — an offset doesn't know about DST, so a meeting scheduled three months ahead would be an hour wrong for half your attendees when the clocks change. IANA names carry the DST rules, so the resolution stays correct indefinitely.

Where this matters

Meetings

Start times, end times, and durations all render in the viewer's zone. RSVP deadline reminders use the zone as well, so "RSVP by Friday" means Friday where you live, not Friday at HQ.

Email notifications

Email is the trickiest case because the recipient hasn't hit the app — but BoardHerald knows their stored timezone, so outbound email bodies render times in that zone. A board member on vacation in Lisbon still sees her meeting time in America/New_York if that's what she set on her profile — until she updates her profile.

.ics calendar attachments

Every meeting invite ships with a proper .ics file. The event uses DTSTART / DTEND in UTC with VTIMEZONE blocks for the attendee's zone — so when it lands in Google Calendar / Outlook / Fantastical, the time is correctly localised. This is the boring-but-vital plumbing most board software gets wrong.

Audit log

The audit log stores timestamps as UTC internally (so ordering is unambiguous) but displays them in the viewer's zone — with a tooltip showing the UTC value for anyone who's cross-referencing.

Resolutions + deadlines

Resolution open/close timestamps and deadlines work the same way — "voting closes at 17:00" is 17:00 in the viewer's zone. The server evaluates closure against a single UTC instant, so there's no ambiguity about which votes made the cut.

12-hour vs 24-hour format

BoardHerald picks the time format from your locale:

  • America/* zones — 12-hour with AM / PM.
  • Every other zone — 24-hour.

You can override this on your profile if the default doesn't match your preference.

Setting defaults

  • User — Profile → Preferences → Timezone. Searchable dropdown of every IANA name.
  • Tenant — Settings → Organisation → Default timezone. Applies to members who haven't set their own override (e.g. new invitees before they hit their profile).
Changing your zone mid-meeting
If you change your timezone while a meeting is in flight, the UI updates immediately — but already-sent emails don't retroactively update. The .ics attachment in your inbox still shows the old zone until you delete and re-import from the meeting page.

Agent behaviour

When an agent calls meetings_list or updates_list, timestamps come back in ISO-8601 with UTC offsets — so the agent can make its own formatting decisions based on the human user's context. The effective timezone of the issuing human is included as a header on every response, so agents can replicate the user's view if that's what the prompt needs.