I know it's old but it's all I have.
I have no idea if the bug still exists but it may save someone time - it cost me quite a lot of time yesterday ;-)
Given a table 'tab' with timeseries with a key of 'key' with a rowtype of just an integer, and a corresponding virtual table v_tab
select first 1 timestamp,reading from v_tab where key = '2d3af6ef74c5e02323e6e0f69552afb3' order by timestamp desc;
this returns 2026-02-06 00:00:00.00000 2259166
Now
select GetClosestElem(ts,'2027-02-11 00:00:00'::datetime year to second,"<").reading,GetClosestElem(ts,'2027-02-11 00:00:00'::datetime year to second,"<").timestamp from tab where key='2d3af6ef74c5e02323e6e0f69552afb3' ;
This, correctly returns 2259166 2026-02-06 00:00:00.00000
select GetClosestElem(ts,'2027-02-11 00:00:00'::datetime year to second,"<=").reading,GetClosestElem(ts,'2027-02-11 00:00:00'::datetime year to second,"<=").timestamp from tab where key='2d3af6ef74c5e02323e6e0f69552afb3';
This returns 2259166 2027-02-11 00:00:00.00000 ie the requested time is ALWAYS retuned if the comparison is '<=' for the timestamp - the value seems to be correct
------------------------------
Clive Eisen
------------------------------