Skip to content

[SPARK-59411][SQL] Support the TIME data type in the width_bucket function - #58706

Open
stevomitric wants to merge 1 commit into
apache:masterfrom
stevomitric:stevomitric/spark-widthbucket-time
Open

[SPARK-59411][SQL] Support the TIME data type in the width_bucket function#58706
stevomitric wants to merge 1 commit into
apache:masterfrom
stevomitric:stevomitric/spark-widthbucket-time

Conversation

@stevomitric

Copy link
Copy Markdown
Contributor

What changes were proposed in this pull request?

Make width_bucket accept the TIME data type. It already supports DOUBLE and interval (year-month / day-time) operands. This PR adds TIME, which is physically a Long (nanoseconds since midnight) and reuses the existing double-based bucket math (no eval/codegen change).

Mixed TIME precisions are allowed and compared on the shared nanos-of-day value.

Why are the changes needed?

DATE/TIMESTAMP get equiwidth bucketing through intervals, but a TIME column could not be bucketed (e.g. bucketing event times across a 09:00–17:00 workday).

Does this PR introduce any user-facing change?

Yes. width_bucket(TIME'12:00:00', TIME'09:00:00', TIME'17:00:00', 8) now returns 4 instead of raising an error.

How was this patch tested?

MathExpressionsSuite unit cases and golden cases in time.sql (bucket edges, reversed range, mixed precision, and null/degenerate inputs).

Was this patch authored or co-authored using generative AI tooling?

Co-Authored-By: Claude Opus 4.8

…ction

`width_bucket` accepted DOUBLE and interval (year-month / day-time) operands but
rejected TIME. TIME is physically a Long (nanoseconds since midnight), so it
slots into the existing double-based bucket math the same way the Long-backed
day-time interval does:

- Add `AnyTimeType` to the three value/min/max `TypeCollection`s.
- Accept `(TIME, TIME, TIME)` in `checkInputDataTypes` (allowing mixed
  precisions, like the interval cases); operands are compared on the shared
  nanos-of-day value.

No change to `computeBucketNumber` / eval / codegen: operands already flow
through `Number.doubleValue()` (interpreted) and long->double widening (codegen).

Tests: `MathExpressionsSuite` unit cases and golden cases in `time.sql` (bucket
edges, reversed range, mixed precision, and null/degenerate inputs).

Co-authored-by: Isaac <no-reply@databricks.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant