The five dt names that are absent because the column type is

#345 landed thirty seven of the forty two names pandas puts on `.dt`. Five are absent rather than declared and refusing, and each of them is absent for the same kind of reason: there is no column type for what it answers.

- `dt.time` and `dt.timetz` answer a time of day. That needs `TypeKind.TIME` in the core and Arrow `time64[us]` across the C Data Interface. `timetz` needs the zone carried alongside it, which `LogicalType` already knows how to do for a timestamp.
- `dt.to_period` answers a period column, which is a type pandas has and firepanda has never had. It is the largest of the five and it is really a request for `pandas.Period` and `PeriodIndex` behind it.
- `dt.to_pydatetime` answers a numpy array of Python `datetime` objects. There is no column of Python objects in firepanda and there is a good argument that there should not be, so the question this one really asks is what the escape hatch out of a firepanda column into ordinary Python looks like. Related to the `tolist` issue filed alongside this one.
- `dt.freq` answers the inferred frequency of a `DatetimeIndex`, which needs frequency inference over an index and a `DatetimeIndex` to infer it over.

## Why they are absent and not refusing

Every argument pandas declares that #345 does not implement raises by name with the reason in the message. These five do the opposite, and the line between the two is that a caller can see a name before they call it. An absent name reads as unimplemented to anything that introspects the surface, including the conformance board, which reports it exactly that way. A name that is present and always raises reads as broken, and it also passes the board's L0 resolution case while failing everything above it, which is a worse description of reality than not being there.

## What they are worth

Seven board runs: five `resolution/dt.*` cases and two `signature/dt.*` cases, and all seven are currently blocked behind #346 along with the forty eight that would pass. So none of this is urgent and none of it is on the critical path. It is written down so that the absence is a decision on the record rather than something that looks like an oversight.

The order that makes sense is `time` and `timetz` first, since they are one column type and the arithmetic behind them is the same civil calendar conversion the other extractors already use, then `freq`, then `to_period`, and `to_pydatetime` only once there is an answer to what leaving a column for Python objects should look like in general.

Start by reading the surface added in #345 and the seven blocked board cases: five resolution/dt.* cases and two signature/dt.* cases. Review the proposed order of time/timetz, freq, to_period, and to_pydatetime, along with the core TypeKind.TIME, Arrow time64[us], LogicalType, and the related tolist issue. Done means each absence is either implemented or recorded as an intentional, testable decision.

Written by the indexing model from the issue text.