fix inconsistency with strict mode of date validation #870
Conversation
| false => date_from_datetime(input, date_err), | ||
| }?, | ||
| // if the error was a parsing error, in lax mode we allow datetimes at midnight | ||
| Err(line_errors @ ValError::LineErrors(..)) if !strict => date_from_datetime(input)?.ok_or(line_errors)?, |
There was a problem hiding this comment.
With apologies I couldn't help golfing this line, with the result of modifying date_from_datetime a little 🙈
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #870 +/- ##
=======================================
Coverage 94.05% 94.06%
=======================================
Files 102 102
Lines 15028 15023 -5
Branches 25 25
=======================================
- Hits 14135 14131 -4
+ Misses 887 886 -1
Partials 6 6
Continue to review full report in Codecov by Sentry.
|
CodSpeed Performance ReportMerging #870 will degrade performances by 43.7%Comparing Summary
Benchmarks breakdown
|
| // otherwise, try creating a date from a datetime input | ||
| false => date_from_datetime(input, date_err), | ||
| }?, | ||
| // if the error was a parsing error, in lax mode we allow datetimes at midnight |
There was a problem hiding this comment.
let date = ...allow datetimes at midnight
This is so strange 😅 what was the original reasoning for allowing this?
Its also inconsistent with Python pydantic/pydantic#7039 (comment)
There was a problem hiding this comment.
Neither its valid json for a date property in a json schema.
There was a problem hiding this comment.
I agree this behaviour is a bit surprising. It originates from #77 so we will have to ask @samuelcolvin for the motivation and if we can remove it!
There was a problem hiding this comment.
Yup we need to evaluate that but it'll be in a separate discussion / PR
|
Is there a way to implement custom serialization and deserialization code for all datetime fields used in a project or deriving from a BaseModel? For example, one user might want to use unix timestamps, while another would prefer ISO dates as strings. This is particularly important now that datetime is not allowed by default when using strict mode. |
|
Currently you'd need to use a type alias everywhere like |
Change Summary
Stops strict dates from accepting timestamp strings, if
strict=Trueat the extra level.Related issue number
Related to pydantic/pydantic#7039
Checklist
pydantic-core(except for expected changes)