feat: add Time type support to date_trunc function

[kumarUjjawal]

Which issue does this PR close?

• Part of Add or update functions corresponding to make_date, to_time, date_bin, date_trunc for Time data types #19025.

Rationale for this change

What changes are included in this PR?

• Added Time64/Time32 signatures to date_trunc
• Added time truncation logic (hour, minute, second, millisecond, microsecond)
• Error for invalid granularities (day, week, month, quarter, year)

Are these changes tested?

Yes

Are there any user-facing changes?

[martin-g]

Suggested change

	"second argument of `date_trunc` must be timestamp, time scalar or array"
	"second argument of `date_trunc` must be a timestamp/time scalar or an array"

[martin-g]

Are those return types correct - Date and String ? Shouldn't they be converted to Timestamp(Nanosecond, None)
I think the reason is here - https://github.com/apache/datafusion/pull/19640/changes#diff-7a6e17bfd876e9e88341d68750224b8a2294d9f401eef2126a49ade1665c336cR228

[Jefffrey]

Are these return types or input types?

[kumarUjjawal]

SELECT arrow_typeof(date_trunc('day', to_date('2024-01-15')));
-- Returns: Timestamp(ns)

SELECT arrow_typeof(date_trunc('day', '2024-01-15'));  
-- Returns: Timestamp(ns)

Yes, the actual runtime return type is Timestamp(Nanosecond), not Date or String.

The coercion from Date / String to Timestamp happens at planning time, before invoke_with_args is called.

The Date / String entries in information_schema represent the signature variants generated by the coercible API’s implicit coercion sources. However, the return_type method receives the already-coerced type (Timestamp) and returns that.

So the functional behavior is correct, this is how coercible signatures are represented in metadata.

[martin-g]

Got it! Thanks!

[Jefffrey]

Thanks @kumarUjjawal & @martin-g