[AURON #1863] Support native Flink UNIX_TIMESTAMP: native scalar function#2409
[AURON #1863] Support native Flink UNIX_TIMESTAMP: native scalar function#2409weiqingy 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.
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}")?, |
| /// Flink `UNIX_TIMESTAMP(value, format)`: parse a formatted date-time string to | ||
| /// a Unix timestamp in seconds, replicating `java.text.SimpleDateFormat` | ||
| /// lenient semantics. |
|
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.
| let naive: NaiveDateTime = match DateTime::from_timestamp(local_sec, 0) { | ||
| Some(dt) => dt.naive_utc(), | ||
| None => return 0, | ||
| }; |
There was a problem hiding this comment.
This compiles as-is with chrono 0.4.45. DateTime::from_timestamp has been an associated function on DateTime<Utc> since chrono 0.4.31, so DateTime::from_timestamp(local_sec, 0) resolves to Option<DateTime<Utc>> here. The native library is built in CI (the flink job builds native, no skip flag) and is green, so a compile error on this line would have failed the build.
|
Both Copilot comments were addressed in ccc3509. Generalized the not-implemented fallthrough message from "spark ext function" to "auron ext function" now that the registry serves Flink too, and clarified the doc comment so the leading |
|
The only failing check is |
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.