When I send 2025-12-31T10:00:00+09:00 through the API (Workflow → Call API to mutateTables), the table shows 19:00 (JST)—a 9-hour shift as if the value was saved as UTC. However, if I copy/paste the same value in the Data Editor, the cell displays 10:00 as expected. It looks like the parsing behavior differs between the API path and the Data Editor. Sending UTC (...Z) or escaping the plus sign (\u002B) did not resolve it. I’d appreciate guidance on root cause and recommended approach.
Environment
Sender: Glide Workflow → Call API
Target APIs:
POST https://api.glideapp.io/api/function/mutateTables
Column type: Date & Time (Respect time zone = ON)
Viewer device time zone: Asia/Tokyo (JST, +09:00)
Expected behavior
If I register 2025-12-31T10:00:00+09:00 (JST) via API, it should display as 10:00 in JST.
Alternatively, sending the equivalent UTC 2025-12-31T01:00:00.000Z should also display as 10:00 for JST viewers.
Actual behavior
After adding the row via API, the table displays 19:00 (JST)—as if 2025-12-31T10:00:00 was interpreted as UTC and then converted to JST (+9h).
If I copy/paste that value in the Data Editor (e.g., paste from the row above), it immediately displays 10:00 as expected.
In short, the API save path and the Data Editor save path appear to use different time parsing behavior, with the API path losing/ignoring the time zone offset.
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
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?
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”?
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!
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:
// 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)
POST https://api.glideapp.io/api/function/mutateTables
Content-Type: application/json
Authorization: Bearer <REDACTED>
{
"appID": "<REDACTED>",
"mutations": [{
"kind": "add-row-to-table",
"tableName": "native-table-<REDACTED>",
"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:
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?
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.
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?