時間型別：date 與 datetime

用途

date 適合生日、到期日與會計日等只在乎日曆日期的資料；datetime 適合預約時段、交貨時間與班次開始時間。例如診所可用 date 記錄看診日，再用 datetime 精確記錄「2026-07-21 14:30」的預約時段。

建立 schema

日期欄的 columns.create body：

{
  "name": "到期日",
  "type": "date",
  "required": false,
  "default_value": "2026-07-31",
  "description": "付款到期日"
}

日期時間欄的 body：

{
  "name": "預約時間",
  "type": "datetime",
  "required": true,
  "default_value": "2026-07-21 14:30",
  "description": "診間預約開始時間"
}

合法與不合法的值

兩種值都是有固定格式的 JSON 字串：

{
  "data": {
    "到期日": "2026-07-31",
    "預約時間": "2026-07-21 14:30"
  }
}

以下值不合法：第一個不是實際存在的日期，第二個使用 ISO 8601 的 T、秒與時區。

{
  "data": {
    "到期日": "2026-02-30",
    "預約時間": "2026-07-21T14:30:00+08:00"
  }
}

後端會分別要求 YYYY-MM-DD 與 YYYY-MM-DD hh:mm。

顯示與回傳

API 會按原格式回傳字串，不會附加時區或自動轉換成本地時間：

{
  "data": {
    "到期日": "2026-07-31",
    "預約時間": "2026-07-21 14:30"
  }
}

datetime 是無秒、無時區的 wall-clock 值。前端如果使用 JavaScript Date，必須在送出前自行格式化，避免 toISOString() 產生不被接受的 T 與 Z。

僅遷移會出現的後端不一致 Schema 從 date 轉成 datetime 時，目前會附加 00:00:00，所以遷移後的資料列可能讀到含秒值，儘管一般紀錄寫入與預設值都拒絕秒。這是遷移輸出，不是合法輸入格式。在後端修正內部不一致之前，前端若要把該值再次寫入，請先正規化成 YYYY-MM-DD HH:mm。

注意事項

• date 嚴格使用 YYYY-MM-DD；datetime 嚴格使用 YYYY-MM-DD HH:mm，中間是空白。
• datetime 不接受秒、小數秒或 UTC offset。
• 唯一已知的含秒形狀是上述遷移產生的 00:00:00 例外；用戶端仍不可送出秒。
• default_value 會使用同一套格式驗證；格式正確但不存在的日期仍會被拒。
• 選填欄的空字串會視為空值；必填欄不可在建立或明確更新時送空值。

試試看

到 API Playground 建立日期欄，再用 records.create 比較空白分隔與 ISO T 分隔的結果。