Skip to content
Open beta — everything’s free right now, and your rate is locked when it ends.

The duration field: reads h:mm, stores seconds

A length of time you type as 1:30 and Tabla stores as 5400 seconds — why that storage makes sums and averages exact, the two display formats, and the API shape.

Updated August 2026

A duration is a length of time — how long a delivery window is, how long a call took. You read and type it as hours and minutes; Tabla stores it as a single number of seconds. In the demo plant shop, Delivery window on the Orders table shows 2:00; the stored value is 7200.

That storage choice is the whole story of this field, so it gets its own section below.

Adding a duration field: the Format select offering 1:30 and 1:30:00 in the field editor.

One option

Format — how the cell reads:

  • 1:30 — hours and minutes (h:mm), the default.
  • 1:30:00 — hours, minutes, seconds (h:mm:ss), for durations where seconds matter.

A value with seconds shown in h:mm displays rounded to the minute; the stored seconds are untouched, and switching the format reveals them again.

Typing durations

Type 1:30 and you get an hour and a half. Type 0:45:30 in the seconds format and you get exactly that. A bare number is read in the smallest displayed unit — 90 in an h:mm field means 90 minutes (1:30), and in an h:mm:ss field means 90 seconds (0:01:30) — so what you type matches what you're looking at. A typo that doesn't parse reverts to the current value rather than storing garbage, and negative durations are refused.

Why seconds make the math right

Sixty is a terrible base for arithmetic, so Tabla never does arithmetic in it. Every duration is one number of seconds, which means summaries, filters, sorts, and rollups are plain numeric operations that happen to display as time. Sum 0:45 and 0:45 and the footer says 1:30 — the engine added 2700 and 2700 and dressed 5400 back up. Nothing is parsed at read time, so nothing can round oddly or drift.

Blank cells behave like any number field's: skipped by Sum and Average, never counted as 0:00. Filtering compares seconds — is greater than with 3600 finds everything over an hour.

Over the API

Seconds, both directions:

{ "fields": { "Delivery window": 7200 } }

Reads are always a number of seconds — format it yourself. Writes accept a number of seconds or a colon string: sending "1:30" stores 5400. A negative value is refused with Field "Delivery window" can't be negative. Clear with null.

Note the difference from typing in the grid: over the API a bare number is always seconds, whatever the display format — the smallest-displayed-unit rule is a screen convenience only.

When it's the wrong field

  • A moment — "delivered at 14:30" is a point in time, not a length of it. That's a date field with time on.
  • Days-long spans — the display tops out at hours (36:00, not 1 day 12:00). Real, but worth knowing before you store project durations; a plain number of days may read better.
  • Derived spans — if the duration is "Deliver by minus Placed", store the two dates and let a formula do the subtraction.

Duration shares the numeric column with the rest of the number family, so converting to a plain number is free — the cells start showing the seconds.

Tabla is the database we build these on.

A no-code database with real Postgres underneath: every feature on every plan, a million records per database, and your whole database back out in one file, any day.

More guides