Skip to main content
RAMBOURG Pierre
Seasoned ⭐️⭐️
RAMBOURG Pierre
Seasoned ⭐️⭐️
January 21, 2026
Solved

Discrepencies behavior between client.time_series.data.retrieve and client.time_series.data.synthetic.query

  • January 21, 2026
  • 2 replies
  • 67 views

Hello everyone,

I observe a difference in behavior that I cannot explain.

My input data, few datapoints, and before the value is 0, timeseries.is_step = True

Input datapoints

With client.time_series.data.retrieve, behavior is as expected :

And with every granularity results are okay as expected.

Nevertheless, with client.time_series.data.synthetic.query it’s… different.

that’s ok
that’s ok

Not ok, why the result is not 2 groups : from 46 to 49 then 49 to 52 ?
 

another wrong example

Why the start timestamp is 48 and not at 46 ?

 

Again, the timeseries endoint is good : 

I have lost hope.

If anyone has anything to try or an explanation, i’ll be grateful.

Thanks in advance,

Pierre

 

    Best answer by matiasholte

    Hi Pierre!
    You have correctly identified a difference between synthetic time series and regular data point retrieval.

    The key difference is that regular aggregates align to start (rounded to granularity unit, 3s aligns to a whole second).
    Synthetic time series, on the other hand, align to epoch. So a 3s aggregate will start at a multiple of 3s since epoch (midnight Jan 1st 1970 in UTC).

    So for your expression, the first multiple of 6s is at 08:15:48. 

    If you want to override this behaviour, follow the link to see how you can override the behaviour (in your case, set the alignment parameter to start time)
     

    (The solution with alignment was added to allow for consistent aggregate borders across paging)
    Hope this helps

    Matias

    2 replies

    matiasholte
    Practitioner ⭐️⭐️⭐️
    matiasholteAnswer
    Backend developer
    January 21, 2026

    Hi Pierre!
    You have correctly identified a difference between synthetic time series and regular data point retrieval.

    The key difference is that regular aggregates align to start (rounded to granularity unit, 3s aligns to a whole second).
    Synthetic time series, on the other hand, align to epoch. So a 3s aggregate will start at a multiple of 3s since epoch (midnight Jan 1st 1970 in UTC).

    So for your expression, the first multiple of 6s is at 08:15:48. 

    If you want to override this behaviour, follow the link to see how you can override the behaviour (in your case, set the alignment parameter to start time)
     

    (The solution with alignment was added to allow for consistent aggregate borders across paging)
    Hope this helps

    Matias

      RAMBOURG Pierre
      Seasoned ⭐️⭐️
      RAMBOURG PierreAuthor
      Seasoned ⭐️⭐️
      January 22, 2026

      Hi Matias,

      Clear as crystal, many thanks !
      I had read the documentation but I hadn't grasped the impact of the alignment parameter.

       

      I have regained hope 😌

      Thanks again,

      Pierre

        Terms & ConditionsAccessibility statement