fix: temporal_derivative reports value/day to match MobilityDB

[estebanzimanyi]

Summary

MEOS's `temporal_derivative` returns slope in value/second (`tsequence_derivative` divides the value-change by `(inst2->t - inst1->t) / 1000000` — microseconds → seconds). MobilityDB's SQL wrapper post-multiplies the MEOS result by 86400 to present the derivative in value/day. MobilityDuck was calling MEOS directly without that scaling, so the result diverged from MobilityDB by a factor of 86400.

Reproducer

```sql
SELECT derivative(tfloat '[1@2000-01-01, 4@2000-01-04]');

-- before fix:
-- Interp=Step;[0.000011574074074@2000-01-01, 0.000011574074074@2000-01-04]

-- after fix (matches MobilityDB):
-- Interp=Step;[1@2000-01-01, 1@2000-01-04]
```

Fix

Wrapper-side: scale the MEOS result by 86400 via `mult_tfloat_float` after `temporal_derivative` returns. Three lines in `Temporal_derivative`.

Coordination with MEOS / MobilityDB

The clean long-term fix would be a non-breaking MEOS API like `temporal_derivative_scaled(temp, double scale)` so callers can pick their preferred time unit without each downstream wrapper re-scaling. Filed a comment on MobilityDB PR #782 (which is already touching `tsequence_derivative`) to coordinate. This MobilityDuck-side fix is a workaround until the MEOS API question is settled.

Surfaced by parity work in PR #23 (026_tnumber_mathfuncs.test). The skip block there can be removed in a follow-up once this lands.

Test plan

• Smoke test confirms post-fix value matches MobilityDB regression expectation
• Existing test suite still passes locally

[estebanzimanyi]

Pushed a follow-up commit fixing CI failure on test/sql/tgeompoint.test:588.

Root cause: the first commit wrapped temporal_derivative to multiply by 86400 for value/day output, but speed(tgeompoint) was registered against the same wrapper — so it got scaled too. The regression test expects speed in distance/second (raw MEOS unit).

Fix: split into a shared static helper TemporalDerivativeCore(args, result, bool scale_to_per_day). Temporal_derivative passes true, new Tpoint_speed passes false. tgeompoint.cpp now registers speed against Tpoint_speed.

Verified:

• derivative(tfloat '[1@..,4@..]') = 1 (value/day, MobilityDB-compatible)
• speed(tgeompoint) = 0.000016... (~√2/86400, MEOS native)
• test/sql/tgeompoint.test passes 148/148 locally

[nhungoc1508]

I checked against MobilityDB's latest implementation and I couldn't find the multiplication by 86400 (also defined as SECS_PER_DAY).

Current MobilityDuck implementation (before applying the commits in this PR) seems to already match the behavior of MobilityDB, for both speed(tgeompoint) and derivative(temporal):

MobilityDB:

SELECT derivative(tfloat '[1@2000-01-01, 4@2000-01-04]');
-- Interp=Step;[0.000011574074074@2000-01-01 00:00:00+00, 0.000011574074074@2000-01-04 00:00:00+00]

SELECT round(derivative(tfloat '{[1@2000-01-01, 2@2000-01-02, 1@2000-01-03],[3@2000-01-04, 3@2000-01-05]}'), 6);
-- Interp=Step;{[0.000012@2000-01-01 00:00:00+00, 0.000012@2000-01-03 00:00:00+00], [0@2000-01-04 00:00:00+00, 0@2000-01-05 00:00:00+00]}

SELECT round(speed(tgeompoint '[Point(1 1)@2000-01-01, Point(2 2)@2000-01-02, Point(1 1)@2000-01-03]'), 6);
-- Interp=Step;[0.000016@2000-01-01 00:00:00+00, 0.000016@2000-01-03 00:00:00+00]

MobilityDuck:

SELECT derivative(tfloat '[1@2000-01-01, 4@2000-01-04]');
-- Interp=Step;[0.000011574074074@2000-01-01 00:00:00+00, 0.000011574074074@2000-01-04 00:00:00+00]

SELECT round(derivative(tfloat '{[1@2000-01-01, 2@2000-01-02, 1@2000-01-03],[3@2000-01-04, 3@2000-01-05]}'), 6);
-- Interp=Step;{[0.000012@2000-01-01 00:00:00+00, 0.000012@2000-01-03 00:00:00+00], [0@2000-01-04 00:00:00+00, 0@2000-01-05 00:00:00+00]}

SELECT round(speed(tgeompoint '[Point(1 1)@2000-01-01, Point(2 2)@2000-01-02, Point(1 1)@2000-01-03]'), 6);
-- Interp=Step;[0.000016@2000-01-01 00:00:00+00, 0.000016@2000-01-03 00:00:00+00]

[estebanzimanyi]

@nhungoc1508 you're right — I checked against the local MobilityDB source and tests, and the premise of this PR is wrong.

Verification:

• mobilitydb/src/temporal/tnumber_mathfuncs.c:470-479 — Temporal_derivative is a thin pass-through, no scaling.
• mobilitydb/sql/temporal/026_tnumber_mathfuncs.in.sql:404-406 — SQL-level derivative(tfloat) calls Temporal_derivative directly, no * 86400.
• meos/src/temporal/temporal.c:2974-2976 — tsequence_derivative divides by (t2 - t1) / 1000000, i.e. produces value per second.
• mobilitydb/test/temporal/expected/026_tnumber_mathfuncs.test.out:1472 — MobilityDB's own regression expects 0.000012@... (value/second). Not 1.0 (value/day).
• Zero occurrences of 86400 or SECS_PER_DAY anywhere in the MobilityDB derivative path.

So MobilityDB returns value/second — exactly what MobilityDuck returned before this PR. The two were already in agreement.

Root cause of the original report: in PR #23, the parity test 026_tnumber_mathfuncs.test recorded the expected output for derivative(tfloat '[1@2000-01-01, 4@2000-01-04]') as 1@... — but that's not what MobilityDB actually outputs. The expected value was simply wrong, and the mode skip comment ("MobilityDB reports value/day") was based on that misread. There is no unit divergence; the parity test fixture itself was incorrect.

Closing this PR. The right follow-up is a small fix on the parity test in PR #23: update the derivative expected output to the actual MobilityDB value (0.000011574... or rounded equivalent) and drop the mode skip block. I'll do that separately.

Apologies for the noise — and thanks for catching this before merge.