Date and Time
A date together with a time — a specific moment rather than a day.
Where to find it
Architect Panel → Data:
- Datastores — the datastore, then Table Designer to add or edit a field
When to use it
- Appointments, bookings and meetings.
- When something happened — received, sent, completed, approved.
- Anything where ordering within a day matters.
Prefer it for events
If the field records something that happened, the time is nearly always worth having even when nobody asks for it today. Two things recorded on the same day are indistinguishable without it, and "which came first" is a question that arrives eventually — usually during an investigation, when it matters most.
Adding time later does not retrofit it to existing records.
Time zones
The question to settle: are your users all in one place?
If they are, this is straightforward. If they are not, be clear whose time a stored moment is in and how it is displayed — an appointment at 2pm means different things in London and New York, and a booking system that gets this wrong fails in a way that is obvious to the customer and confusing to support.
Do not use it for a plain date
A date of birth stored with a time is a date that can shift across a day boundary under time-zone conversion. Use the plain date type where the time genuinely has no meaning.
Automatic timestamps
Where the value records when a record was created or changed, remember the audit trail already captures that — with the acting identity and the before-and-after state, which a field does not.
A "date created" field is still worth having when the value is business-meaningful and needs to be reportable or editable. It is not worth having purely to know when a row appeared.
Defaults
Defaulting to now suits fields recording an action as it happens. It is the wrong default for a planned future moment, where an empty field prompts a real decision and a default invites somebody to accept it.
Displaying it
Seconds are rarely useful to a reader. Where the field is business information rather than a technical timestamp, showing minutes is usually enough — precision that nobody uses is noise on every screen it appears on.
Worked example
A service records enquiries with a date and time received, defaulted to now. Response-time reporting works because the ordering within a day is real. The related "target resolution date" is a plain date, because a target expressed to the minute would be false precision.
Recommendations
- Use it for anything that happened, even if time seems irrelevant today.
- Settle time zones before going live with distributed users.
- Do not duplicate the audit trail with technical timestamps.
- Display to the precision people use.