[DaZuiZui]

Description

Fixes #19264.

DateBinFunctionColumnTransformer.convertToTimestamp computed the result as
toEpochMilli() + getNano(). toEpochMilli() already contains the whole
milliseconds of the second, and getNano() is the full nanosecond-of-second
(0–999_999_999), not the remainder below one millisecond. The intra-second
milliseconds were therefore counted twice, so month/year bins started that many
milliseconds late. For example date_bin(1mo, time, 500) returned 1000 for a
source of 500 and 2678401000 for 2678400500.

The fix converts from Instant.getEpochSecond() and Instant.getNano(), so each
part of the instant is counted exactly once, for ms, us and ns precision.

Hour and day bins do not use this helper and are unaffected. Month bins with a
whole-second origin are also unaffected because getNano() is 0 for them.

How to reproduce

CREATE DATABASE testdb;
USE testdb;
CREATE TABLE t (device_id STRING TAG, s INT32 FIELD);
INSERT INTO t (time, device_id, s) VALUES
  (500, 'd1', 1),
  (2678400500, 'd1', 2);
SELECT time, date_bin(1mo, time, 500) FROM t ORDER BY time;

Before: 1000 and 2678401000. After: 500 and 2678400500.

Tests

Added cases in DateBinFunctionTest for the issue's scenario, a 2024 origin,
dateBinStartEnd, nextDateBin, and us/ns precision with a sub-second
origin.

Tests run: 12, Failures: 0, Errors: 0, Skipped: 0

🤖 Generated with Claude Code