date_time

Data type date_time, probed on Version.client_approved_at (stock, editable).

Across Version, Project, Shot, Task, Note, 3 of 14 date_time fields are editable: true: Version.client_approved_at, Version.media_center_import_time, Project.last_accessed_by_current_user. created_at/updated_at and the rest are server-managed. The name does not predict it (client_approved_at is writable, viewed_by_current_user_at is not); read the schema's editable flag.

Read Plain string in attributes, never relationships, identical from GET /entity/versions and POST /entity/versions/_search:

  created_at='2026-01-23T20:43:39Z'   updated_at='2026-03-16T07:54:00Z'

Always YYYY-MM-DDTHH:MM:SSZ: second resolution, literal trailing Z, no numeric offset and no site-local zone. A Version created at client UTC 2026-09-02T15:58:53.5Z read back created_at='2026-09-02T15:58:53Z': 0.5s truncated, the same instant.

Write PUT /entity/versions/<id> with a JSON string.

A POST is the other half: created_at and updated_at are accepted in a create body and stored exactly as sent, on Note, Task and Version, and created_at on Reply, although the schema flags both editable: false (probe 070).

Clear

A cleared field is matched by ["field", "is", null] (1) and excluded by is_not null (0).

Filter The bogus-operator 400 (probe 017) on Version.created_at:

  "title": "API read() Version.created_at's 'date_time' data type doesn't support
            'definitely_not_an_operator' 'relation'",
  "source": {"Version.created_at": " ... Valid relations: [\"is\", \"is_not\", \"greater_than\",
      \"less_than\", \"in_last\", \"not_in_last\", \"in_next\", \"not_in_next\", \"in_calendar_week\",
      \"in_calendar_month\", \"in_calendar_day\", \"in_calendar_year\", \"between\", \"in\", \"not_in\"]"}

Shot.sg_turnover_date, a date field, returns an identical list; the two types share every relation and differ only in value format. There is no not_between and no is_null.

Every count below is one sandbox Version holding 2026-03-04T05:06:07Z, run on 2026-09-02: 1 is a match, 0 is a miss.

A filter value takes the same formats as a write value, date-only included, and a date-only value is exactly midnight UTC rather than a day:

Re-stored on the current UTC date, the same row matched in_calendar_day 0 at both 00:30Z and 23:30Z and matched neither -1 nor +1, with _week, _month and _year at 0 each 1: the calendar buckets are UTC-aligned, with no site-local offset.

Traps

• A written offset is not preserved: 05:06:07+05:00 reads back as 00:06:07Z. Convert to UTC yourself and keep the original zone in your own field if a client must redisplay local wall-clock time.
• A zoneless string is assumed UTC, not site-local: "2026-03-04T05:06:07" is not "5am here".
• is is exact-second equality, so is "2026-03-04" finds only rows at 00:00:00Z. Match a day with between ["2026-03-04", "2026-03-05"] or in_calendar_day.
• "" 400s where a text field accepts it; only null clears. There is no numeric form: epoch integers 400 with the [String, NilClass] type error, epoch strings with the format error.
• editable: false on a timestamp means "not editable by a PUT", not "not settable". The 400 says so outright, is editable on create only, and a create body sets both (probe 070). Test the create path rather than reading the flag.