Follow-up from #187 and the generated RowBinary encoder work.
PR #187 sketched a faster DateTime path for values close to now by precomputing date/month Unix offsets and deriving the final timestamp from struct fields instead of calling the general DateTime/NaiveDateTime conversion helpers for every row value.
Current behavior should stay correct and conservative: non-UTC DateTime types remain rejected for encoding, DateTime64 precision is preserved, and values outside any optimized range fall back to the existing implementation.
Suggested scope:
- Benchmark the current generated encoder DateTime and DateTime64 paths separately from other column work.
- Prototype precomputed UTC month/day offsets for NaiveDateTime and UTC DateTime values.
- Decide the supported optimized range and fallback behavior.
- Add parity tests against
Ch.RowBinary.encode/2 for DateTime and DateTime64 values, including nils and boundary dates.
- Update
bench/encode.exs with a focused DateTime case if the optimization is worthwhile.
Follow-up from #187 and the generated RowBinary encoder work.
PR #187 sketched a faster DateTime path for values close to now by precomputing date/month Unix offsets and deriving the final timestamp from struct fields instead of calling the general DateTime/NaiveDateTime conversion helpers for every row value.
Current behavior should stay correct and conservative: non-UTC DateTime types remain rejected for encoding, DateTime64 precision is preserved, and values outside any optimized range fall back to the existing implementation.
Suggested scope:
Ch.RowBinary.encode/2for DateTime and DateTime64 values, including nils and boundary dates.bench/encode.exswith a focused DateTime case if the optimization is worthwhile.