One timezone per database: what it changes and what it never touches

A date-and-time value in Tabla is stored as one exact instant, in UTC. The database's timezone decides how that instant is read: which clock it displays as, which calendar day it belongs to, and what "today" means in a filter. One timezone per database — not per person — so a team in Cairo, Berlin and Toronto reads one consistent clock instead of three private ones.

New databases start on UTC.

Set it

1. Click the database name in the top bar.
2. Under Time zone, pick from the list — the standard IANA names, Africa/Cairo, Europe/Berlin, about 400 of them.

The change applies immediately, for every member. Editors and owners can change it. Two sibling settings sit under it in the same menu — Week starts on and Weekend (with presets including Friday + Saturday) — which the calendar follows.

What it affects

Each of these is the same rule wearing different clothes: day boundaries are drawn in the database's timezone.

• Display. A date field with time shows and edits as the wall clock in the database's timezone, in the grid and the record panel both. The stored instant never moves; the clock face does.
• Filters. Filtering a date-and-time field by a bare date — "Placed is 2026-08-05" — means that entire day in the database's timezone, midnight to midnight. The relative values (today, and its offsets) resolve to the calendar day the database's clock currently shows.
• The calendar. Records bucket onto the day they fall on in the database's timezone; the "today" highlight and the day the calendar opens on follow the same clock, so the highlight and your filters can never disagree about what day it is.
• Webhook conditions. A condition on a date-and-time field draws its day boundaries in the database's timezone, exactly like the grid filter — a trigger and a filter with the same terms agree about which day a record falls on.

What it never touches

• The stored value. Changing the timezone rewrites nothing. The same instants, shown on a different clock — which near midnight can mean a different calendar day on screen.
• Date-only fields. A date without a time — 2026-08-13 — has no timezone anywhere. It displays, filters and exports verbatim, the same in every zone.
• The API and webhook payloads. Over the API, and in every webhook delivery, a date-and-time value is the UTC instant, ISO 8601 ending in Z. The timezone is presentation; the wire format doesn't bend.
• Exports. The CSVs in a database export carry the same UTC instants, so an export re-imports exactly. A spreadsheet opened elsewhere may therefore show a different clock time than Tabla does — the zip's own README says so in as many words.

The honest edges

Daylight saving is handled, with one narrow exception. The zones carry their own DST rules, so displayed clocks shift when the zone shifts — nothing to configure. The exception: typing a wall-clock time that falls inside a DST transition's skipped or repeated hour lands on one side of the fold, and there is no way to say which you meant. It's one hour, twice a year, in zones that observe DST at all.

Formulas compute on UTC days. A formula that reads a date-and-time field works from its UTC calendar date, not the database timezone's — a value late in the evening local time can count as the next day inside a formula. (Formulas also can't know today's date at all; that one is on the wishlist.)

The questions people ask

Can each member see their own timezone? No. One database, one clock, on purpose — "the meeting is on the 14th" should mean the same row to everyone who can see it.

I changed the timezone and some records show a different day now. That's the feature working. The instants didn't move; the day boundary did. Records within a few hours of midnight are the ones that cross it.

Which timezone should a distributed team pick? The one your operations live in — where deliveries happen, where the workday is anchored. Ties go to wherever the person who reads the calendar most is sitting.