fix(promql): read sample values in date functions with an argument

[fengyue-xve]

What's changed

PromQL date functions that take an argument — minute, hour, month, year, day_of_month, day_of_week, day_of_year and days_in_month — should read each sample value as a Unix timestamp in seconds (UTC), but the planner applied them to the sample's time index instead, so every series reported the calendar component of the evaluation instant:

TQL EVAL (0, 5, '5s') minute({"semantic.probe"})   -- sample values 120 and 180
-- before: 0, 0                                      after: 2, 3

The fix reworks the date-function arms of create_function_expr:

• With an argument, each field column is read as a Timestamp(Second) — the float → int conversion truncates towards zero — and date_part (or the days_in_month expression) is computed from the sample value. Non-finite and out-of-i64-range values (NaN, ±Inf, 1e19) resolve to the Unix epoch instead of failing the query, harmonizing with Prometheus' int64(sample), whose overflow cases are implementation-defined in Go (proposal: cmd/compile: floating point to integer conversions should saturate on overflow golang/go#76264; 0 on arm64). Each expression is aliased to <function>(<column>) so the conversion does not become the output column name.
• Without an argument, behavior is unchanged: the function reads the evaluation instant carried by the time index.
• Native histogram samples are skipped, like Prometheus: the materialized float alternative column carries the value when present, otherwise the column evaluates to NULL and the row is dropped by the empty-value filter.

days_in_month is factored into a shared days_in_month_expr helper so both paths build the same expression; it selects the month length from date_part("month")/date_part("year") with a proleptic Gregorian leap-year CASE instead of date_trunc("month", ts), which scaled seconds to nanoseconds and overflowed past ~year 2262.

Tests

Updated the sqlness expectations for the changed output column names (time_fn.result, dotted_column_names.result) and added a regression case in time_fn.sql with ten sample values covering all eight functions: calendar components that deliberately differ from the evaluation instants, a fractional value (59.9 → 59), a negative one (-1.5 → 1969-12-31T23:59:59Z), and non-finite, out-of-range and year-3000 values (NaN, inf, -inf, 1e19, 32503680000), which must yield a point (the Unix epoch) instead of failing the query. Planner tests pin that the date functions drop native histogram samples when they are the only field columns, and skip the histogram column when a float alternative carries the same sample. The existing no-argument cases are kept to pin the default behavior.

Fixes #9393

[killme2008]

Skipping native histogram samples is new behavior and nothing pins it: removing the field_column_is_native_histogram branch keeps every test green. sqlness cannot ingest histograms, so a planner test along the lines of test_mixed_or_routes_float_histogram_and_label_functions would cover it.

[killme2008]

Cast runs with safe: false, so a NaN or ±Inf sample fails the whole query ("Can't cast value NaN to type Int64"), e.g. hour(foo / bar) with a zero bar. Before this change these functions never read the value, and Prometheus still emits a point for it. Use TryCast so the value becomes NULL and the row is dropped by the empty-value filter. days_in_month has the same problem past ~9.2e9 s: date_trunc scales seconds to nanoseconds and errors with "Timestamp out of range".

[killme2008]

My TryCast suggestion is incomplete: it drops non-finite samples, while Prometheus still emits them, and it does not prevent the later date_trunc overflow. Cover non-finite inputs and year-3000 sample values against Prometheus before choosing the conversion.

[fengyue-xve]

Both points were right — I reworked the conversion around what Prometheus actually emits.

The sample is now read as coalesce(TRY_CAST(v AS Timestamp(Second)), epoch), guarded by an IS NOT NULL case: a non-finite or out-of-i64-range value becomes the Unix epoch rather than NULL, so the row survives and a point is emitted. That harmonizes with Prometheus, where the value goes through int64(v): Go leaves the overflow cases implementation-defined (golang/go#76264) and int64(NaN) is 0 on arm64, so the epoch is the portable result. NULL stays NULL — a skipped native histogram column has no sample — and keeps dropping the row instead of turning it into a 1970 point.

days_in_month no longer goes through date_trunc("month", ts), which scaled seconds to nanoseconds and failed past ~2262: it reads date_part("month")/date_part("year") and selects the month length with a proleptic Gregorian leap-year CASE, the same rule as time.Date in Prometheus.

time_fn.sql pins NaN, ±Inf, 1e19 and a year-3000 sample value for all eight functions, and the planner tests pin how the date functions skip native histogram columns.

07ca67f

[killme2008]

Hi @fengyue-xve, a friendly ping: the open points from the previous review still apply to 07dd1ed. The strict Cast errors on NaN, ±Inf and out-of-range samples (arrow casts numeric → Timestamp through Int64 with safe: false), and the native histogram skip has no test. Please pin the non-finite and year-3000 outputs against Prometheus in time_fn.sql before picking the conversion. Happy to help if anything is unclear.

[killme2008]

nit: days_in_month never uses the "day" from the _ arm. Match it explicitly and keep date_part to the seven date_part functions, so a new name added to the outer arm fails to compile instead of silently mapping to "day".

[fengyue-xve]

Done in 48c7e37, and it still holds at the current head: days_in_month has its own arm (with no date_part unit), the inner match holds exactly the seven date_part units and ends in unreachable!, so a new name in the outer arm fails to compile.

[killme2008]

Please merge the latest main into this branch to catch up with the current codebase, then rerun the relevant PromQL planner tests and sqlness cases.

[killme2008]

TRY_CAST accepts finite values such as 1e13, but Arrow's date_part returns NULL outside Chrono's calendar range. The empty-value filter then drops the sample, whereas Prometheus returns year 318857 and minute 46. Handle this extraction boundary without silently losing samples, and add a regression for 1e13.

[fengyue-xve]

Done in a39b5963d — merged the latest main into the branch and pushed. Rust CI (workspace nextest, including the PromQL planner tests) and Integration CI (sqlness) are rerunning on this head.