feat(polars): add more accurate type mapping for timestamps

[ncclementi]

• Closes refactor(polars): more accurate type mapping for timestamps #8479

polars datetime types have a fixed time unit (us, ns, or ms). Ibis timestamp types do too (but we also have seocnds as an option). In the case of polars we're currently mapping all timestamps to ns, this PR makes things a bit more specific and uses proper units.

I'm still not sure how to handle the case Ibis seconds to maybe ms in polars ? Need a bit help on how the conversion of units happens, more specifically where is the value part handled? we would need to do ibis_seconds*1000 = polars_ms at the moment I'm raising, similarly to what we do in durations, but I need to tackle this differently, see all the current failures in CI.

[ncclementi]

I added this because it seemed like this

ibis/ibis/expr/datatypes/core.py

Lines 619 to 620 in 9355281

	else:
	raise ValueError(f"Invalid scale {self.scale}")

wasn't covered.

But turns out this test is causing a raise in a different place, which is confusing.

[gforsyth]

The Timestamp op has a restriction that only the literal ints from 0 through 10 can be passed as scale -- so while it isn't technically unit-tested, it's not possible to set a value outside of that range without raising a SignatureValidationError

[ncclementi]

That makes sense, but then why having a code path to "raise" that would never been triggered.

[gforsyth]

i would wager that the raise predates the enforcement of values at the op level

[ncclementi]

@jcrist in the original issue, you suggested maybe defaulting to "ms" for when we go from "s" in Ibis to polars. I though it made sense keeping the behavior we had before for that particular case which is "ns". Any objections?

[cpcloud]

It still seems a bit odd to me that asking for seconds I would get back milliseconds. I say we raise in the seconds case as an UnsupportedOperationError the same any other missing functionality.

[ncclementi]

This will break the current behavior where we ask for seconds and return ns. Just making sure we are ok with breaking that.

[ncclementi]

After looking more into this PR, I'm not sure if we are correctly casting the values when mapping the timestamps, base on this code:

ibis/ibis/backends/polars/compiler.py

Lines 157 to 171 in b48f451

	if dtype.is_integer():
	typ = pl.Datetime(time_unit="us", time_zone=time_zone)
	arg = (arg * 1_000_000).cast(typ)
	if time_unit != "us":
	arg = arg.dt.truncate(f"1{time_unit}")
	return arg.alias(op.name)
	elif dtype.is_string():
	typ = pl.Datetime(time_unit=time_unit, time_zone=time_zone)
	arg = arg.str.strptime(typ)
	if time_unit == "s":
	return arg.dt.truncate("1s")
	return arg
	typ = PolarsType.from_ibis(to)
	return arg.cast(typ, strict=strict)

That being said the casting "potential issue" is separate from the mapping of the types, so I proposed opening a separate issue to investigate that, and for now get this PR in.

[ncclementi]

I did a little more digging and on main (as well as this branch). The casting is broken, see #9091

I'm not sure what are the next steps here, regarding this PR.

[cpcloud]

@ncclementi Anything blocking this PR? I know it's been awhile, but does it make sense to merge this in for 9.2?

[ncclementi]

Technically no, as the typing gets fixed in this PR, although the actual casting is kind of broken see #9091.

Let me rebase, and kick CI again. I'd be ok merging this and we can look into the casting of the values in a followup.

[cpcloud]

LGTM, thanks!