Time
A time of day on its own, with no date attached.
Where to find it
Architect Panel → Data:
- Datastores — the datastore, then Table Designer to add or edit a field
What it stores
A time — half past nine — without saying which day. That is the whole character of the type and the source of both its uses and its misuses.
When it is right
- Recurring times — opening hours, a daily deadline, a shift start.
- A time paired with a separate date, where the two are genuinely independent.
- Durations expressed as a clock value, where that is the convention.
When it is wrong
For a specific moment. If the answer to "which day?" matters, use date and time rather than a time field alongside a date field.
Two separate fields can disagree, can be filled in half, and have to be recombined for every comparison — sorting by "when did this happen" across a date field and a time field is markedly more awkward than sorting one column.
The recurring case is where it shines
Opening hours are the clearest example: nine to five, every weekday, with no date involved. Storing that as a date and time would require inventing a date, and the invented date would then appear in reports and confuse people.
Watch the midnight boundary
A shift running from 22:00 to 06:00 has an end time numerically smaller than its start. Any comparison or duration calculation needs to handle that, and code that assumes end is after start will produce a negative duration.
This is the classic bug with time fields, and it is worth thinking about before somebody enters a night shift.
Validate the range where it applies
Where a time must fall within a window — appointment slots within opening hours — validating at entry saves a booking that cannot be honoured.
Decide the precision
Most business uses want minutes. Offering seconds invites people to enter them and produces values nobody reads. Match the field to how the value is actually used.
Worked example
A venue datastore stores opening and closing times per weekday as time fields, with no dates involved — which is correct, because they recur. Individual bookings against that venue use date and time, because each is a specific moment. The booking form validates the time falls within the venue's hours.
Recommendations
- Use it for recurring times, not for moments.
- Never pair a date field with a time field to represent one moment.
- Handle the midnight crossing in anything that compares times.
- Offer minutes, not seconds, unless seconds are genuinely used.