weiqingy opened a new pull request, #2409: URL: https://github.com/apache/auron/pull/2409
TITLE: [AURON #1863] Support native Flink UNIX_TIMESTAMP: native scalar function --- # 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: https://github.com/weiqingy/auron/pull/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_TIMESTAMP` converts 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.SimpleDateFormat` in 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 format `yyyy-MM-dd HH:mm:ss` as 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_UnixTimestamp` ext scalar function in `datafusion-ext-functions`, registered through the existing ext-function path (no proto change). It takes three string arguments `[value, format, zoneId]` and returns an `Int64`. The format is a translated strftime-style pattern and the zone is resolved by the caller; the converter PR supplies both. The parser reproduces `SimpleDateFormat` lenient 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), since `GregorianCalendar` is 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.SimpleDateFormat` across 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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
