Budibase/budibase · error · HTTPError
Invalid format for field "${columnName}": "${columnData}". D
Error message
Invalid format for field "${columnName}": "${columnData}". Datetime fields with ignoreTimezones must be in ISO format, e.g. "YYYY-MM-DDTHH:MM:SS". What it means
This HTTP 400 error is thrown by the row-parsing logic in packages/server/src/utilities/schema.ts when a value supplied for a DATETIME column that has `ignoreTimezones: true` in its schema does not match the ISO format without a timezone suffix (checked by isValidISODateStringWithoutTimezone, e.g. "YYYY-MM-DDTHH:MM:SS"). Because ignoreTimezones columns are stored as UTC with a "Z" appended internally, any offset like "+02:00" or a trailing "Z" in the input would corrupt the stored value, so it is rejected up front.
Source
Thrown at packages/server/src/utilities/schema.ts:182
if (
schema[columnName].autocolumn &&
!table.primary?.includes(columnName)
) {
// Don't want the user specifying values for autocolumns unless they're updating
// a row through its primary key.
return
}
const columnSchema = schema[columnName]
const { type: columnType } = columnSchema
if ([FieldType.NUMBER].includes(columnType)) {
// If provided must be a valid number
parsedRow[columnName] = columnData ? Number(columnData) : columnData
} else if (columnType === FieldType.DATETIME) {
if (columnData && !columnSchema.timeOnly) {
if (columnSchema.ignoreTimezones) {
if (!sql.utils.isValidISODateStringWithoutTimezone(columnData)) {
throw new HTTPError(
`Invalid format for field "${columnName}": "${columnData}". Datetime fields with ignoreTimezones must be in ISO format, e.g. "YYYY-MM-DDTHH:MM:SS".`,
400
)
}
parsedRow[columnName] = new Date(columnData.trim() + "Z")
} else {
if (!sql.utils.isValidISODateString(columnData)) {
let message = `Invalid format for field "${columnName}": "${columnData}".`
if (columnSchema.dateOnly) {
message += ` Date-only fields must be in the format "YYYY-MM-DD".`
} else {
message += ` Datetime fields must be in ISO format, e.g. "YYYY-MM-DDTHH:MM:SSZ".`
}
throw new HTTPError(message, 400)
}
}
}
if (columnData && columnSchema.timeOnly) {View on GitHub (pinned to a81a902e9a)
Solutions
- Strip the timezone portion before sending: send "YYYY-MM-DDTHH:MM:SS" with no Z or offset, after converting to UTC yourself.
- If offsets are meaningful, disable ignoreTimezones on the column so timezone-suffixed values are accepted.
- Pre-validate the string with the same regex/isValidISODateStringWithoutTimezone check before calling the API.
- For imports, transform date columns in the source file to the timezone-less ISO format.
Example fix
// before
row["due"] = new Date().toISOString() // "2024-01-05T10:00:00.000Z"
// after
const d = new Date()
const pad = (n: number) => String(n).padStart(2, "0")
row["due"] = `${d.getUTCFullYear()}-${pad(d.getUTCMonth() + 1)}-${pad(d.getUTCDate())}T${pad(d.getUTCHours())}:${pad(d.getUTCMinutes())}:${pad(d.getUTCSeconds())}` // "2024-01-05T10:00:00" Defensive patterns
Strategy: validation
Validate before calling
const ISO_NO_TZ = /^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}$/
function validNoTzIso(v: string) {
return ISO_NO_TZ.test(v.trim()) && !isNaN(new Date(v.trim()).getTime())
}
if (!validNoTzIso(row.due)) row.due = toUtcNoTzIso(row.due) Type guard
function isIsoNoTz(v: unknown): v is string {
return typeof v === "string" &&
/^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}$/.test(v.trim()) &&
!isNaN(new Date(v.trim()).getTime())
} Try / catch
try {
await saveRow(row)
} catch (e) {
if (e instanceof HTTPError && e.status === 400 && /ignoreTimezones/.test(e.message)) {
row.due = toUtcNoTzIso(row.due)
await saveRow(row)
} else throw e
} Prevention
- Convert to UTC and strip the Z/offset before sending to ignoreTimezones columns
- Never feed new Date().toISOString() directly into ignoreTimezones fields
- When toggling a column to ignoreTimezones, reformat existing client payloads first
- Pre-validate dates in import pipelines with the same ISO regex
When it happens
Trigger: Uploading/creating rows where a datetime column marked ignoreTimezones receives a value with a timezone suffix: "2024-01-05T10:00:00Z", "2024-01-05T10:00:00+02:00", a locale string like "05/01/2024 10am", or a plain date "2024-01-05" that fails the regex.
Common situations: Importing CSV exports from systems that always append Z or offsets; clients sending new Date().toISOString() output (which ends in Z); switching a column to ignoreTimezones after data was written with offsets; API integrations posting JavaScript date strings.
Related errors
- Invalid format for field "${columnName}": "${columnData}". D
- Import data or url is required
- Unsupported import type
- Cannot make field "${key}" required, it has a default value.
- Config id not found
AI-assisted analysis of Budibase/budibase@a81a902e9a (2026-08-29).
Data as JSON: /api/errors/cc484b29b387bc5f.
Report an issue: GitHub.