[AURON #1863] Support native Flink UNIX_TIMESTAMP: native scalar function#2409
Open
weiqingy wants to merge 2 commits into
Open
[AURON #1863] Support native Flink UNIX_TIMESTAMP: native scalar function#2409weiqingy wants to merge 2 commits into
weiqingy wants to merge 2 commits into
Conversation
…r function Add the native Rust half of Flink's UNIX_TIMESTAMP: a scalar ext function that parses a formatted date-time string to a Unix timestamp in seconds, matching Flink's java.text.SimpleDateFormat lenient semantics. The parser reimplements lenient field parsing (rollover, non-padded fields, trailing input tolerance), the Julian/Gregorian hybrid calendar (cutover 1582-10-15), and DST resolution via the zone's standard offset for ambiguous or nonexistent local times. Unparseable input yields Long.MIN_VALUE; NULL input yields NULL; arity is validated. The function is registered but unreferenced until the Flink converter that emits it is added, so this change is self-contained.
Contributor
There was a problem hiding this comment.
Pull request overview
Adds a native (Rust) implementation of Flink’s UNIX_TIMESTAMP as an ext scalar function in the DataFusion extension layer, including a lenient parser intended to match java.text.SimpleDateFormat behavior, and wires it into the existing ext-function registry (dormant until planner/converter support lands).
Changes:
- Register new ext scalar function name
Flink_UnixTimestampin the shared ext-function factory. - Implement a lenient, SimpleDateFormat-like date/time string parser with timezone/DST and hybrid Julian/Gregorian calendar handling.
- Add unit tests covering parsing leniency, rollover, DST gap/overlap, failure semantics (
i64::MIN), and NULL propagation.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| native-engine/datafusion-ext-functions/src/lib.rs | Registers Flink_UnixTimestamp in the ext-function factory. |
| native-engine/datafusion-ext-functions/src/flink_datetime.rs | Implements the native Flink UNIX_TIMESTAMP evaluator and its unit tests. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| } | ||
| "Spark_IsNaN" => Arc::new(spark_isnan::spark_isnan), | ||
| "Flink_UnixTimestamp" => Arc::new(flink_datetime::flink_unix_timestamp), | ||
| _ => df_unimplemented_err!("spark ext function not implemented: {name}")?, |
Comment on lines
+30
to
+32
| /// Flink `UNIX_TIMESTAMP(value, format)`: parse a formatted date-time string to | ||
| /// a Unix timestamp in seconds, replicating `java.text.SimpleDateFormat` | ||
| /// lenient semantics. |
Contributor
Author
|
Hi @Tartarus0zm, could you please help review this PR when you get a chance? Thanks! |
… native doc The registry now dispatches Flink functions in addition to Spark, so the not-implemented fallthrough message no longer says spark. Also clarify that the doc comment's UNIX_TIMESTAMP(value, format) refers to the Flink SQL function, distinct from the native arity-3 [value, chronoFormat, zoneId] contract described just below it.
Comment on lines
+334
to
+337
| let naive: NaiveDateTime = match DateTime::from_timestamp(local_sec, 0) { | ||
| Some(dt) => dt.naive_utc(), | ||
| None => return 0, | ||
| }; |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Which issue does this PR close?
Part of #1863. The converter that emits this function follows in a separate PR, once this one merges.
To show where this is going, the converter change is previewable here: weiqingy#1 (a draft in my fork, diffed against this PR's branch so it shows only the converter side). That PR will be opened against this repo after this one lands.
Rationale for this change
Flink's
UNIX_TIMESTAMPconverts a formatted date-time string to a Unix timestamp in seconds. AIP-1 lists it as a Phase 1 built-in function. Supporting it natively is the first step; this PR adds the native (Rust) evaluation, and a follow-up PR wires the Flink converter to emit it.The hard part is matching Flink's parsing exactly. Flink parses with
java.text.SimpleDateFormatin its default lenient mode, so it accepts non-zero-padded fields, field rollover, and trailing input. A strict parser diverges from Flink on the default formatyyyy-MM-dd HH:mm:ssas soon as a field is not zero-padded, and would return a wrong timestamp rather than an error. So this implements a lenient parser rather than delegating to a strict one.What changes are included in this PR?
A new
Flink_UnixTimestampext scalar function indatafusion-ext-functions, registered through the existing ext-function path (no proto change).It takes three string arguments
[value, format, zoneId]and returns anInt64. The format is a translated strftime-style pattern and the zone is resolved by the caller; the converter PR supplies both.The parser reproduces
SimpleDateFormatlenient semantics for the supported fields: variable field widths, rollover normalization, tolerant of trailing input, a leading minus on numeric fields. It also handles the Julian/Gregorian hybrid calendar (cutover 1582-10-15), sinceGregorianCalendaris a hybrid while chrono is proleptic Gregorian, and resolves DST-ambiguous or nonexistent local times using the zone's standard offset, matching Flink.Failure semantics match Flink: an unparseable string yields
Long.MIN_VALUE, a NULL input yields NULL, and the milliseconds-to-seconds step truncates toward zero.The function is registered but not yet emitted by any planner, so this PR is self-contained and dormant until the converter lands.
Are there any user-facing changes?
No. The function is not reachable from SQL until the converter PR is merged.
How was this patch tested?
18 unit tests derived from a differential oracle that was validated against real
java.text.SimpleDateFormatacross a large randomized set of (input, format, timezone) inputs. Coverage includes the happy path, field rollover, non-padded fields, trailing garbage, NULL, unparseable-to-Long.MIN_VALUE, DST gap and overlap across several zones, pre-1970 negative timestamps, pre-1582 hybrid-calendar dates, the arity guard, and canonical field widths.