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).