When datafusion.execution.parquet.coerce_int96 is set, timestamp type is still reported as Timestamp(nanoseconds)

[alamb]

Describe the bug

datafusion.execution.parquet.coerce_int96 is supposed to

If true, parquet reader will read columns of physical type int96 as originating from a different resolution than nanosecond. This is useful for reading data from systems like Spark which stores microsecond resolution timestamps in an int96 allowing it to write values with a larger date range than 64-bit timestamps with nanosecond resolution.

However, when I set this to ms the type is still reported to be Timestamp(Nanoseconds)

To Reproduce

-- Enable coercion of int96 to microseconds
set datafusion.execution.parquet.coerce_int96 = ms;

-- Create external table
CREATE EXTERNAL TABLE int96_from_spark
STORED AS PARQUET
LOCATION 'parquet-testing/data/int96_from_spark.parquet';

-- Print schema
describe int96_from_spark;

Results in

+-------------+-----------------------------+-------------+
| column_name | data_type                   | is_nullable |
+-------------+-----------------------------+-------------+
| a           | Timestamp(Nanosecond, None) | YES         |
+-------------+-----------------------------+-------------+
1 row(s) fetched.
Elapsed 0.001 seconds.

Expected behavior

I expect the output type to be Timestamp(Microsecond, None)

Additional context

• The new feature was added in Add coerce int96 option for Parquet to support different TimeUnits, test int96_from_spark.parquet from parquet-testing #15537
• Possibly related to Unable to debug print large Timestamp(TimeUnit::Microsecond) values arrow-rs#7287

[alamb]

• FWIW I don't think this is a blocker for Release DataFusion 47.0.0 (April 2025) #15072

[andygrove]

Thanks @alamb. @mbutrovich fyi

[chenkovsky]

take