fix(read): support Parquet TIME columns

[QuakeWang]

Purpose

Closes #292.

TIME schemas were rejected, and field mapping required a logical cast type even for identical Arrow types. This prevented reading existing Parquet TIME columns.

Parse and validate TIME as time32[ms], matching Java Paimon, and skip cast lookup for identical types. Millisecond values and nulls are preserved, including PyPaimon's TIME(0).

Tests

• Passed: 7 parser, 85 core, 69 Parquet reading tests, the new TIME integration test, and an actual PyPaimon 2.0.0 table scan/read.
• Full-repository pre-commit and git diff --check passed.
• macOS core/read tests required static relinking. Full common tests hit an existing compilation error; full Parquet tests aborted in a VECTOR test. Lance was not enabled.

API and Format

No public API or storage format changes. Scope is reading existing Parquet TIME columns.

Documentation

No documentation changes.

Generative AI tooling

Generated-by: OpenAI Codex (GPT-6)

[lxy-9602]

Thank you for the contribution! Before reviewing this PR in detail, I’d like to confirm the intended scope of the implementation. Does this PR only support reading append tables? It seems primary key tables may require additional changes, for example around FieldsComparator.

Also, although the TIME schema can pass validation during creation, it currently cannot be serialized when create table— for example, calling ToJsonString() fails with an unknown type error.

[QuakeWang]

Thank you for the contribution! Before reviewing this PR in detail, I’d like to confirm the intended scope of the implementation. Does this PR only support reading append tables? It seems primary key tables may require additional changes, for example around FieldsComparator.

Also, although the TIME schema can pass validation during creation, it currently cannot be serialized when create table— for example, calling ToJsonString() fails with an unknown type error.

@lxy-9602 Yes, this PR currently targets reading existing append-only Parquet tables. I should have made that clearer in the description. You’re right about PK tables.

I checked the merge path, and RowToArrowArrayConverter also needs TIME support, beyond the comparator changes.

I missed the serialization gap. I’d like to address that here and leave PK support for a separate PR. Does that scope work for you? For serialization, we’ll also need to decide how to handle precision, since the current mapping to time32[ms] loses the original TIME(p) precision.

[lxy-9602]

I missed the serialization gap. I’d like to address that here and leave PK support for a separate PR. Does that scope work for you? For serialization, we’ll also need to decide how to handle precision, since the current mapping to time32[ms] loses the original TIME(p) precision.

Thanks for your reply! Yeah, I agreed that PK support should be a separate pr. I think C++ can follow the paimon-rust design: preserve TIME(p) in the Paimon logical schema and treat Arrow time32[ms] only as the execution/storage representation. Serialization should use the preserved logical precision instead of inferring it from the Arrow type. If introducing a separate logical type model is out of scope for this PR, storing the original precision in Arrow field metadata could be a transitional solution. Does this look good to you?

[QuakeWang]

Updated in c23c267. TIME precision is now preserved in Arrow field metadata and used for serialization, with TIME(0) as the default when metadata is absent. Added round-trip tests and updated the compatibility tests. PK support will stay in a separate PR.

[lxy-9602]

+1