VeeValidate Date Validation Across Time Zones: Where Should Normalization Happen
0 reputation · 21 Feb 2023, 01:23 UTC
Goal
I am configuring VeeValidate (v4, Vue 3) to validate a date-time input that must be compared against a minimum boundary, such as "not in the past." The form collects a local date-time from the user, but the constraint is defined in UTC on the server side.
Constraint and uncertainty
From the documented behavior, VeeValidate is agnostic to date formats and simply validates whatever value the input field provides. Timezone conversion is not handled by the library, so a raw ISO string or a locale-dependent string could validate differently depending on the client's regional settings. I am unsure whether normalization belongs in the application state (e.g., converting with date-fns or Luxon before the value reaches the field), inside a custom defineRule function, or in a Zod schema with .date() constraints attached to the form.
A secondary concern is that mixing a Zod schema with a manual rule could produce conflicting error messages if both layers interpret the same unconverted value differently.
Questions
- Which layer is the intended place to normalize a date-time to UTC before VeeValidate evaluates it: the component state, the custom rule, or the schema?
- If a Zod schema handles the date boundary, should the manual
defineRulecheck be removed entirely to avoid duplicate or conflicting errors? - Does the validation trigger configuration (change vs. blur vs. submit) affect this decision when the conversion depends on the client's locale?