Action isoTimestamp allows space in UTC offset

[frenzzy]

Fixes:

• isoTimestamp only accepts UTC timestamps #495

Changes:

• Updated ISO 8601 timestamp regex to allow a single space before timezone offset (e.g., +00:00).

Reason:

• PostgreSQL’s timestamptz default output includes a space before the timezone offset:

  SELECT NOW()::timestamptz;
  -- → '2025-05-13 14:15:41.123904 +00:00'

• This aligns with the SQL standard output format, even though it’s not strictly ISO 8601 compliant.
• The change improves compatibility with real PostgreSQL data and prevents false validation errors.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
valibot	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jun 30, 2025 9:16am

[Copilot]

Pull Request Overview

This PR updates the ISO 8601 timestamp regex to accept a single space before the timezone offset for better compatibility with PostgreSQL’s timestamptz output.

• Allow an optional space before the UTC offset in ISO_TIMESTAMP_REGEX.
• Add tests covering timestamps with a space before the offset.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
library/src/regex.ts	Updated ISO_TIMESTAMP_REGEX to accept a leading space before +/- offset.
library/src/actions/isoTimestamp/isoTimestamp.test.ts	Added a test suite for timestamps with a space before the UTC offset.

[fabian-hiller]

Thank you for creating this PR! Are you aware of any drawbacks? I'm a bit concerned because it doesn't seem to be ISO 8601 compliant.

[frenzzy]

Thank you for asking! I agree this tweak isn’t strictly ISO 8601, but I don’t anticipate any serious drawbacks, mainly because it matches common real-world usage. For example, PostgreSQL’s timestamptz has for years output a space before the offset by default (following the SQL standard formatting). This means strings like "2025-05-13 14:15:41.123904 +00:00" are already out there – even modern JavaScript engines handle that format just fine (Date.parse() / new Date() don’t error on it in my testing).

Also, our current ISO_TIMESTAMP_REGEX isn’t a fully strict ISO 8601 validator anyway – we’ve already allowed a space instead of "T" between date and time, and the timezone offset was designed to be optional. In that light, permitting a leading space before the +/- offset is consistent with our pragmatic approach. It lets developers validate timestamps exactly as PostgreSQL emits them without having to pre-process the string or write a custom regex.

In short, this change improves compatibility with real data (avoiding false validation errors on perfectly valid SQL-standard timestamps) while staying aligned with the library’s goal of being practical and developer-friendly.

[fabian-hiller]

Sorry for my late reply! I agree but I want to look at other schemas library like Zod first to see how they handle it. For now, I would plan to release this as a "fix" with Valibot v1.2.