[Enh]: Add support for Binary & Time datatype

[FBruzzesi]

Description

We have support for the large majority of polars dtypes, yet missing a few:

• Binary
• Time

[dangotbanned]

We have support for the large majority of polars dtypes, yet missing a few. One of which is Binary

@FBruzzesi another one that I noted in altair.datasets._cache, was Time.
I haven't seen an issue for it before, but would have thought Time might be more common to use than Binary?

Feel free to move this to another issue, just wanted to collect some knowledge on missing types:

General

• https://json-schema.org/draft/2020-12/json-schema-validation#name-dates-times-and-duration
• https://datapackage.org/standard/table-schema/#time

Implementations

• pandas seems to not support directly
  • dask and any others dependant on numpy would have the same limitations
• spark not supported
• polars.Time
• pyarrow.Time32Type and pyarrow.Time64Type
• duckdb.TimeValue and duckdb.TimeTimeZoneValue
• ibis.expr.datatypes.core.Time

[MarcoGorelli]

thanks both

I think we should have both data types - even if we can't always support casting to it for all backends, if these datatypes are present, we should at least reported them as Time / Binary as opposed to Unknown

[FBruzzesi]

Thanks for pointing that out @dangotbanned , I will edit the issue in a bit to be more comprehensive for all the missing types

[dangotbanned]

Thanks @MarcoGorelli, @FBruzzesi

Just to argue against myself a little bit on nw.Time from L75

    # nw.Time: "time" (Not Implemented, but we don't have any cases using it anyway)

Per #1942:

Freeze new features which don't have a use case.

I think it makes sense to support, but I'm not losing any sleep over the status quo 🙂

[MarcoGorelli]

I think this fine, a couple new data types doesn't really add much bloat (as opposed to, say, implementing an entire new namespace)