timestamp Field Type
type: 'timestamp' marks a field as a machine-generated epoch timestamp — a numeric Unix value (seconds or milliseconds) or an ISO datetime string from a system log, audit trail, or event stream. Pair it with renderAs: 'timestamp' and the correct parseMode for the source format.
Core Examples
epoch-sec and epoch-ms
The two most common timestamp formats in backend systems. parseMode tells the renderer how to interpret the raw number.
Two timestamp columns from the same dataset — one in Unix seconds, one in Unix milliseconds. Both render identically with the correct parseMode.
// Unix seconds
{
key: 'updatedAtEpochSec',
label: 'Updated',
type: 'timestamp',
renderAs: 'timestamp',
renderAsOptions: { parseMode: 'epoch-sec', locale: 'en-US', timezone: 'utc', formatPreset: 'medium' },
}
// Unix milliseconds
{
key: 'ingestedAtEpochMs',
label: 'Ingested',
type: 'timestamp',
renderAs: 'timestamp',
renderAsOptions: { parseMode: 'epoch-ms', locale: 'en-US', timezone: 'utc', formatPreset: 'medium' },
}
Sorting
Timestamps sort chronologically in table mode when parseMode is declared and sortable: true is set.
Table pre-sorted descending by epoch-sec timestamp. Click the column header to toggle sort direction.
{
key: 'updatedAtEpochSec',
label: 'Updated',
type: 'timestamp',
renderAs: 'timestamp',
sortable: true,
renderAsOptions: { parseMode: 'epoch-sec', locale: 'en-US', timezone: 'utc', formatPreset: 'medium' },
}
Field Options Reference
| Option | Type | Default | Effect |
|---|---|---|---|
key | string | required | Entity property to read the timestamp value from. |
label | string | unset | Column header or card label. |
type | 'timestamp' | — | Marks the field as a machine-generated epoch value. Pair with renderAs: 'timestamp'. |
renderAs | 'timestamp' | unset | Required for formatted output. Without it, raw value renders as plain text. |
condition | (entity) => boolean | unset | Hides the field for rows where the function returns false. |
sortable | boolean | false | Enables column sorting. Sorts chronologically when parseMode is set. |
width | CSS length or number | unset | Sets column width in table mode. |
align | 'left', 'center', 'right' | 'left' | Text alignment in table mode. |
renderAsOptions for renderAs: 'timestamp'
parseMode is required — without it the field renders 'Invalid'. All other display options (formatPreset, locale, timezone, relativeTime, showSeconds, hour12, formatOptions, etc.) are documented on the timestamp Renderer page.
Caveats
parseModeis required. Without it, the field renders'Invalid'.epoch-secandepoch-msare the two most common choices. Mixing them (e.g. passing milliseconds withepoch-sec) produces a date far in the future — verify your source format.type: 'timestamp'andtype: 'datetime'share the same renderer internally (renderTemporalwithkind: 'datetime'). The distinction is semantic: timestamp signals a machine-generated epoch value; datetime signals a human-authored date+time.parseMode: 'any'attempts multiple formats in order. Use it only when the source format is genuinely unknown — it is less reliable than explicit modes.
Why timestamp vs datetime?
Both accept epoch values with parseMode: 'epoch-ms' or 'epoch-sec' and render identically. The distinction is semantic:
type: 'timestamp'— the value comes from a system clock, audit log, or event stream. The epoch integer is the primary form.type: 'datetime'— the value is a human-readable ISO string authored to represent a specific point in time.
Using the correct type communicates intent clearly and will matter for future features like inline editing (timestamp fields would get a read-only display; datetime fields might get a datetime picker).
See Also
- timestamp Renderer — full
renderAsOptionsreference - Temporal Fields Guide — cross-type contracts, sorting behavior, migration checklist
- datetime Field Type
- date Field Type
- Item Config — item-level shape and layout contract
- Field Config