Looks solid, great work!

One general comment is that this approach (the previous also) may make it difficult to support timestamps with timezones (more generally, logical types whose number of variants is very large and can't be enumerated).

To address this in arrow2, what I did was to not rely on a trait to map logical information. For example:

fn subtract<T: PhysicalType>(lhs: &PrimitiveArray<T>, rhs: PrimitiveArray<T>) -> PrimitiveArray<T> {
    // ...
    let data_type = lhs.data_type().clone();
    PrimitiveArray::from_data(data_type, values, validity)
};

if we use something like

fn subtract<T: LogicalType>(lhs: &PrimitiveArray<T>, rhs: PrimitiveArray<T>) -> PrimitiveArray<T> {
    // ...
    PrimitiveArray::from_data(LogicalType::DATA_TYPE, values, validity)
};

the DATA_TYPE can't be described in timestamps with timezones because we need more information (the timezone).

In other words, for timezones, we will need to implement something like

impl Int64Chunked {
    pub fn into_datetime(self, tz: Option<String>) -> DatetimeChunked {
        DatetimeChunked::new(self, tz)
    }
}

and there won't be any .into(). Also means that

fn subtract<T: LogicalType>(lhs: &PrimitiveArray<T>, rhs: PrimitiveArray<T>) -> PrimitiveArray<T> {
    // ...
};

may not make sense when two timezones are not equal (i.e. when lhs.dtype() != rhs.dtype()).

I think we can figure out this later, just pointing out that this was one of the things that I went back and forth in arrow2.

Agreed, the runtime DataType should dictate, not the statically known T. What I am thinking about for timestamp, is to have Logical<ChunkedArray<T>, Field>, where Field holds the runtime dtype. The statically known into_date would not work indeed. I am thinking to do the same as you did in arrow2: ChunkedArray<T>::to(DataType). Then DataType can hold all the timezone and precision information.
.
Note that almost all operations are dispatched to the physical type now and that only when going to and from arrow, and casting we need to check the logical type.

I think we can figure out this later, just pointing out that this was one of the things that I went back and forth in arrow2.

Yes, there are probably a lot of edge cases, once timezones come in to play. Maybe its a good idea to cast the ArrayRef to their logical type before using arrow2 kernels (now I only use the physical arrays). Then these edge cases can be maintained in one code base.

Thanks for the review, good to know we are on the good path for this.