",
"columnValues": {
"date_col": "2025-12-31",
"dt_col_1": "2025-12-31T10:00:00+09:00",
"dt_col_2": "2025-12-31T01:00:00.000Z"
}
}]
}
```
## Troubleshooting already done
- Added a **plain text “raw\_iso” column** and stored the exact string alongside the Date & Time column to confirm the literal value (including `+09:00`) is preserved.
- Reproduced with both **offset** (`+09:00`) and **UTC** (`Z`) forms.
- Built the body via a **JSON template** and sent the **raw JSON** to avoid any internal encoding of `+`.
- Tested **single-row** POSTs and **batched** POSTs.
- Re-verified the target column is **Date & Time (Respect time zone = ON)** and not a text/calculated column.
## Questions
1. Do the **API paths** (`mutateTables`) and the **Data Editor** use different **time parsing implementations**?
If there’s a known difference or specification, could you point me to it?
2. Given that both **JST with `+09:00`** and **UTC with `Z`** still shift when sent via API, what is the **officially recommended format** (e.g., RFC 3339 with specific precision) for Date & Time columns with “Respect time zone = ON”?
3. In the **Call API** handling, could timestamps containing `+` or `Z` be transformed internally before reaching storage?
Are there any **known issues** with `mutateTables` ingestion of offset/UTC timestamps?
I’m unsure at which layer the interpretation changes. Any guidance on a reliable workaround or the correct format/usage for the API would be greatly appreciated. Thank you!
---
### Author:  [@ThinhDinh](https://community.glideapps.com/u/ThinhDinh)
#### Post date: [August 21, 2025, 1:19am UTC](https://community.glideapps.com/t/time-zone-parsing-for-date-time-via-api-differs-from-pasting-in-the-data-editor/83920/2 "2025-08-21T01:19:50Z")
> [@Big Tables - date/time column offset issue](https://community.glideapps.com/t/big-tables-date-time-column-offset-issue/75513/11):
>
> Well, that response you got from Support is not what I would have expected, so I just did a bit of testing. I created a new table and added some rows via the API, using curl from a terminal. Here are the results: (NB: this was with a regular table. See further below for results with a Big Table.) In the above: The first column is a date/time column with respect time zone enable The second column is a date/time column with respect time zone not enabled …
Here’s the leg work @Darren_Murphy did a while ago.
---
### Author:  [@koki](https://community.glideapps.com/u/koki)
#### Post date: [August 21, 2025, 8:52am UTC](https://community.glideapps.com/t/time-zone-parsing-for-date-time-via-api-differs-from-pasting-in-the-data-editor/83920/3 "2025-08-21T08:52:45Z")
Thanks for running those tests and sharing the screenshots — super helpful.
To clarify my environment: I’m using a **regular Glide Table** (not a Big Table), and I’m writing via **API v1** (`POST ``https://api.glideapp.io/api/function/mutateTables`) triggered from a **Workflow → Call API** action. The target column is **Date & Time with “Respect time zone” = ON** , and my local time zone is **Asia/Tokyo (UTC+9)**.
### What I’m seeing
When I add a row via **Call API → mutateTables** with any of the following payloads, I consistently get a 9-hour shift as if the value were treated as UTC:
```auto
// 1) Offset form (JST 10:00)
"2025-12-31T10:00:00+09:00"
// 2) Escaped plus
"2025-12-31T10:00:00\u002B09:00"
// 3) UTC equivalent (JST 10:00 == UTC 01:00)
"2025-12-31T01:00:00Z"
"2025-12-31T01:00:00.000Z"
```
Result in the table (JST view): **19:00** for the first two, and still not the intended **10:00** even with the `Z` forms.
If I then **copy/paste the same value in the Data Editor** (from the row above) the display immediately corrects to **10:00**. So it looks like the **API save path** and the **Data Editor save path** are parsing differently in my case.
### Minimal example (v1: mutateTables)
```auto
POST https://api.glideapp.io/api/function/mutateTables
Content-Type: application/json
Authorization: Bearer
{
"appID": "",
"mutations": [{
"kind": "add-row-to-table",
"tableName": "native-table-",
"columnValues": {
"dt_col": "2025-12-31T10:00:00+09:00"
// also tried the \u002B form and the Z forms above
}
}]
}
```
### What I already tried
- Sending **offset** (`+09:00`), **escaped plus** (`\u002B`), and **UTC Z** (`...Z`, with seconds/millis).
- Building the body as a **raw JSON string** (JSON Template column) and passing it directly in Call API to avoid any internal encoding of `+`.
- Testing **single-row** vs **batched** POSTs.
- Verifying the target is a **Date & Time** column (not a text/calculated column) with **Respect time zone = ON**.
- Adding a parallel **text column** to store the literal ISO string (“raw\_iso”) and confirming the incoming text is intact (including `+09:00`) even when the Date/Time column shows the shifted time.
Given your results with a regular table (and that it generally “does the right thing”), my case seems unexpected. Two questions:
1. Is there any **known difference** in how timestamps are parsed when the request comes specifically from **Workflow → Call API** (vs cURL/Postman)? In other words, could Call API be transforming or re-encoding the body before it reaches `mutateTables`?
2. For **API v1 + Glide Table** , is there a **canonical timestamp format** that will be parsed identically to the Data Editor (for a Date/Time column with Respect ON)? If so, could you share the exact expected shape (e.g., RFC 3339 with mandatory seconds/millis, any constraints on offsets, etc.)?
If there isn’t anything else I can do on the API side, I’ll switch to one of these workarounds:
- Use **Date/Time with “Respect time zone” OFF** (fixed display for a Japan-only audience), or
- Split into **Date** + **Time (text/number)** columns and compose for display.
Happy to provide a minimal repro app, raw request/response logs, or a short screen recording showing “19:00 → 10:00” after pasting in the Data Editor, if that helps. Any further pointers would be greatly appreciated.
---
### Author:  [@ThinhDinh](https://community.glideapps.com/u/ThinhDinh)
#### Post date: [August 22, 2025, 12:30am UTC](https://community.glideapps.com/t/time-zone-parsing-for-date-time-via-api-differs-from-pasting-in-the-data-editor/83920/4 "2025-08-22T00:30:41Z")
Your questions would only be correctly answered by a Glide engineer. As a fellow user, I would say what about sending the time at UTC+0 instead of trying to represent the current Japan time?