Skip to content

Deprecate Expr temporal part arguments in date extraction and truncation functions#1587

Open
kosiew wants to merge 3 commits into
apache:mainfrom
kosiew:deprecation-typehint-01-1496
Open

Deprecate Expr temporal part arguments in date extraction and truncation functions#1587
kosiew wants to merge 3 commits into
apache:mainfrom
kosiew:deprecation-typehint-01-1496

Conversation

@kosiew

@kosiew kosiew commented Jun 9, 2026

Copy link
Copy Markdown
Contributor

Which issue does this PR close?

Rationale for this change

Temporal functions such as date_part, date_trunc, and their aliases conceptually expect a literal date/time part (for example, "year" or "month"). While the current API also accepts an Expr, that usage is confusing because it suggests arbitrary expressions are intended inputs.

This change begins the deprecation process by warning when an Expr is passed for the part argument while preserving existing runtime behavior.

What changes are included in this PR?

  • Added a shared helper to emit a DeprecationWarning when an Expr is passed to a literal control argument.

  • Updated the implementations of:

    • date_part
    • datepart
    • extract
    • date_trunc
    • datetrunc

    to warn when part is provided as an Expr.

  • Refactored alias functions (datepart, extract, and datetrunc) to delegate through internal helper functions so warnings reference the user-facing function name correctly and avoid duplicate warning behavior.

  • Updated existing temporal function tests to use the preferred string-literal form for part.

  • Added targeted tests verifying:

    • Expr inputs emit DeprecationWarning for date_part, datepart, and extract.
    • Expr inputs emit DeprecationWarning for date_trunc and datetrunc.
    • String literal inputs continue to work without emitting deprecation warnings.

Are these changes tested?

Yes.

The PR updates existing temporal function tests and adds the following deprecation-focused test coverage:

  • test_date_part_expr_part_warns_deprecated
  • test_date_trunc_expr_part_warns_deprecated

It also verifies that preferred string-literal usage does not emit DeprecationWarning by running:

  • test_date_part_native_str
  • test_date_trunc_native_str

with deprecation warnings treated as errors.

Are there any user-facing changes?

Yes.

Passing an Expr (for example, literal("year")) as the part argument to temporal extraction and truncation functions now emits a DeprecationWarning advising users to pass a Python literal string instead.

Runtime behavior and query results remain unchanged in this release.

LLM-generated code disclosure

This PR includes code, comments generated with assistance from LLM. All LLM-generated content has been manually reviewed and tested.

kosiew added 3 commits June 9, 2026 19:33
- Added a deprecation warning helper in `functions.py` to warn users when an `Expr` is passed to:
- `date_part`
- `datepart`
- `extract`
- `date_trunc`
- `datetrunc`
- Kept plain string paths unchanged.

test: enhance tests for deprecation warnings

- Added tests in `test_functions.py` to check for deprecation warnings.
- Implemented no-warning checks for native strings.
- Updated an existing temporal test to use strings to reduce warning noise.
- Changed f.date_part(literal("month"), ...) to f.date_part("month", ...)
- Changed f.extract(literal("day"), ...) to f.extract("day", ...)
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