Implement val_temporal_unit for deciding how datetimes and dates timestamps get validated.

[ollz272]

Change Summary

Follow up to #1743 and a part of pydantic/pydantic#11504 implementation - allows the config switch val_temporal_unit to be used to determine how dates and datetimes timestamps are validated - either as seconds, milliseconds, or inferred.

NOTE - the original ticket makes mention of this also working for time and duration. As far as i can see, we do not currently infer the value of these, they're just assumed to be seconds. Theres no support for this in speedate anyway. So I've implemented what is currently possible. I see 3 possible outcomes from this:

1. We decide that this is fine for all time and this only supports date/datetime
2. We decide that it should support time/duration, but its fine to get this part done first and add support for those later
3. We decide that it should support time/duration, and it needs to go in at the same time.

Related issue number

Checklist

• Unit tests for the changes exist
• Documentation reflects the changes where applicable
• Pydantic tests pass with this pydantic-core (except for expected changes)
• My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

Selected Reviewer: @davidhewitt

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 101 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/validators/config.rs	0.00%	24 Missing ⚠️
src/validators/date.rs	0.00%	24 Missing ⚠️
src/input/datetime.rs	0.00%	22 Missing ⚠️
src/input/input_json.rs	0.00%	10 Missing ⚠️
src/validators/datetime.rs	0.00%	8 Missing ⚠️
src/input/input_python.rs	0.00%	7 Missing ⚠️
src/input/input_string.rs	0.00%	6 Missing ⚠️

📢 Thoughts on this report? Let us know!

[codspeed-hq]

CodSpeed Performance Report

Merging #1751 will not alter performance

_{Comparing ollz272:val_temporal_unit_2 (e984613) with main (d523cf5)}

Summary

✅ 157 untouched benchmarks

[ollz272]

Note - added a test here as this is the pr I discovered the issue with fractional millisecond timestamps (pydantic/pydantic#12027)

[ollz272]

Please review

[ollz272]

Note - i've also added a fix for: #1750 in this commit: 67fcdc3

[davidhewitt]

Thanks for working on this, and sorry for the slow review.

Overall looks great, with just a couple thoughts.

We decide that it should support time/duration, but its fine to get this part done first and add support for those later

This feels ok to me, let's just sense check:

• presumably for milliseconds time values these can never overlap with seconds time values due to the limit of time being 24 hours. So this is safe to go in later as a new feature (would make values previously not accepted be valid).
• for duration, the scale is presumably the same as datetime so we should consider if it makes sense to have inference there at all. IIRC the milliseconds scale kicks in for a timestamp which is on the order of hundreds of years? (we should sense check this). So it's unlikely but possible that this changes the meaning of valid values. In which case implementing this might be a separate issue we should consider for v3?

[davidhewitt]

I wonder if it makes sense to just pass &DateTimeConfig here to simplify things?

[ollz272]

I think i chose not to as i wasn't a fan of using something from the serialization module in the validation logic. Happy to be overridden though!

[davidhewitt]

Potentially worth adding a utility function in speedate DateTime::from_float_with_config?

[ollz272]

pydantic/speedate#86

[ollz272]

Thanks for working on this, and sorry for the slow review.

Overall looks great, with just a couple thoughts.

We decide that it should support time/duration, but its fine to get this part done first and add support for those later

This feels ok to me, let's just sense check:

• presumably for milliseconds time values these can never overlap with seconds time values due to the limit of time being 24 hours. So this is safe to go in later as a new feature (would make values previously not accepted be valid).
• for duration, the scale is presumably the same as datetime so we should consider if it makes sense to have inference there at all. IIRC the milliseconds scale kicks in for a timestamp which is on the order of hundreds of years? (we should sense check this). So it's unlikely but possible that this changes the meaning of valid values. In which case implementing this might be a separate issue we should consider for v3?

Both make sense to me 👍🏻