Rust Interval definition incorrect

[david542542]

It seems the Rust INTERVAL definition is incorrect. Please see duckdb/duckdb-wasm#1696 (comment) for more details on the bug and where it occurs in the code.

Particularly this definition:

arrow-rs/arrow-array/src/types.rs

Lines 265 to 269 in 36a6e51

	```text
	┌──────────────────────────────┬─────────────┬──────────────┐
	│ Nanos │ Days │ Months │
	│ (64 bits) │ (32 bits) │ (32 bits) │
	└──────────────────────────────┴─────────────┴──────────────┘

[tustvold]

@pitrou do you know if the integration tests cover the interval types?

@avantgardnerio as the author of #2235 which appears to have switched these round, perhaps you could weigh in here

[avantgardnerio]

@avantgardnerio as the author of #2235 which appears to have switched these round, perhaps you could weigh in here

Honestly, I don't recall the reasoning. I know at the time I was working with JDBC interop, so I assume it was to make that work.

I agree we should do whatever arrow-cpp does, as that seems to be the reference implementation, to the extent that there is one.

[pitrou]

@pitrou do you know if the integration tests cover the interval types?

Yes, they do.
https://github.com/apache/arrow/blob/7003e90c113cec58a620deddf56af71eb305af2a/dev/archery/archery/integration/datagen.py#L1653-L1669

[tustvold]

One way to avoid this leading to subtle downstream breakage might be to do something along the lines of #3125

[alamb]

Typing down some things that @tustvold told me today:

1. we think the tests ensure the data round trips but does not actually ensure both ends interpret them in the same way (aka they don't cover this particular bug)
2. He plans to work on this ticket, likely next week(ish)
3. In order to avoid subtle breaking changes (due to the same type i128 being interpreted differently by different versions) he plans to do something like Structured Interval Native Type #3125

[alamb]

@tustvold reports is that it is unlikely that this will be done this week due to other higher priorities