-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Datetime validation without offset should allow omission of Z zone designator #2385
Comments
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This is still an issue. I am still working on the draft PR for it. |
I've opened PR that adds optional support for local (unqualified) date times here #2913 |
My workaround is just to refine for now. This also makes seconds optional. const Timestamp = z
.string()
.refine(
(value) => /^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}(:\d{2}(\.\d+)?)?$/.test(value),
{
message:
"timestamp must be of the unqualified form yyyy-mm-ddThh:mm[:ss[.mmm]]",
},
); Example on where unqualified timestamps can come from using upcoming TC39 Temporal > Temporal.Now.plainDateTimeISO('UTC').toString()
'2023-11-25T03:56:32.870588264'
> Temporal.Now.plainDateTimeISO('UTC').toString({smallestUnit: 'minute'})
'2023-11-25T03:56' |
This is an issue as well for us, dealing with OpenAPI We are using zod-to-openapi to build clients for services we use - it sees an OpenAPI schema like But we have an API that actually returns a datetime with no trailing The root problem is that API - but having a workaround in Zod would be very useful. |
Just encountered this same issue |
This is almost a year old. Please prioritize this Zod team. I'm here because Zod validation is failing on dates coming from our ERP system. edit: we decided to just use a |
This is available in canary and will land in Zod 3.23. |
If you also land here and wonder why this is closed but still doesn't work and there is nothing about it in the documentation: This is mentioned (only) in the release notes for v3.23.0: const schema = z.string().datetime({ local: true });
schema.parse("2022-01-01T12:00:00"); // OK |
ISO-8601 allows datetime strings to not have any timezone offset or Z zone designator. In these instances, it is assumed to be in local time. (Reference: https://en.wikipedia.org/wiki/ISO_8601#Local_time_(unqualified))
However, the datetime validator currently marks these as invalid.
The text was updated successfully, but these errors were encountered: