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

  1. Strip the timezone portion before sending: send "YYYY-MM-DDTHH:MM:SS" with no Z or offset, after converting to UTC yourself.
  2. If offsets are meaningful, disable ignoreTimezones on the column so timezone-suffixed values are accepted.
  3. Pre-validate the string with the same regex/isValidISODateStringWithoutTimezone check before calling the API.
  4. 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

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


AI-assisted analysis of Budibase/budibase@a81a902e9a (2026-08-29). Data as JSON: /api/errors/cc484b29b387bc5f. Report an issue: GitHub.