API Gateway Session API: Consistent +8 Hour Offset in Time-Based Filters

MIP
, ,
1

We are experiencing unexpected behavior in the API Gateway’s session API when registering a session using a time-based filter.
The Issue When we register a session using the following filter with an ISO 8601 UTC timestamp (Z suffix):
{
“operator”: “gt”,
“target”: “time”,
“value”: “2026-01-05T07:00:47.910Z”
}

and then fetch alarms for the current sessions, the response only includes alarms starting from 15:00 Z. Valid alarms occurring between 07:00 Z and 15:00 Z are missing.
To verify the consistency of this offset, we adjusted the filter to 06:30 UTC:
Input: …T06:30:00.00Z
Actual Result: The response returned alarms starting from 14:30 Z.

Despite providing the filter in ISO 8601 UTC format with the ‘Z’ suffix, we are observing a consistent +8 hour offset. We suspect the server may be interpreting the input time as local time and incorrectly adding +8 hours when converting or comparing it to UTC.

2

Please share the request you make and I will try to reproduce your observation in the Milestone test lab.

3

Here is the request I have made to register the session :

curl -L 'https://<server-url>:8080/api/rest/v1/alarmSessions' \

-H 'Authorization: bearer {token}' \
-H 'Content-Type: application/json' \
-d '{

 "filterBy": [{
      "operator": "gt",
      "target": "time",
      "value": "2026-01-05T07:00:47.91Z"
   }],
 "orderBy": [{
      "target": "time",
      "direction": "asc"
  }]

}'

In response I got :-

{"id":{session Id},"filterBy":[{"operator":"gt","target":"time","value":"2026-01-05T06:00:47.91Z"}],"orderBy":[{"target":"time","direction":"asc"}]}

Now I have fetched the alarms in current session using below API :-

curl -L 'https://<server-url>:8080/api/rest/v1/alarmSessions/{sessionId}/alarms?maxSize=5' \

-H'Authorization:bearer{token}'

In the response, the alarm with the earliest timestamp was:
"time": "2026-01-05T15:31:06.617Z"

Following this, I registered a new session using this filter:
{
"operator": "gt",
"target": "time",
"value": "2026-01-05T06:00:47.91Z"
}

In the resulting response, the alarm with the earliest timestamp was:
"time": "2026-01-05T14:10:08.037Z"

This indicates that this specific alarm was skipped in the first request.

4

What is your time zone? If you are not working directly on the server please give me the information for both the server and for the workstation you are working on sending the requests. For now it is a hunch that this information is relevant, please let me know.

5

I cannot reproduce. One thing strikes me as odd. Between the query to register the session and the response there seems already to be a difference of one hour ( “2026-01-05T07:00:47.91Z” “2026-01-05T06:00:47.91Z” ) can you confirm this observation (double-check)?
I do get the same time back and I am wondering if this might be a clue for us going forward in our troubleshooting efforts.

6

Do you have many alarms? Does it make a difference if you omit the “?maxSize=5” (if feasible please test).

7

The timezone of the workstation/client which is sending the request is GMT, and the timezone of the server is PST.

I double-checked this, and the timestamp in the API response actually matches the timestamp in my request perfectly. It looks like I just made a typo in my previous forum post.

Yes, we have a large number of alarms, so we have to use maxSize parameter. However, I did test the request without the maxSize parameter, and it still did not work

8

The 8 hours difference is not random but fits the time difference.

As a first step please double-check that both client and server is correctly setup, has the correct time zone, and if you get the time in UTC they are actually in sync.