You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OK, I see what’s going on. It has to do with time zones, specifically time zones that are east of GMT.
When the API call to get the ping results is sent, the start and end dates are specified. Often we don’t care about the end date, and send ‘null’ for that, but we typically do care about the start date, which in this case looks something like this: 2023-01-25T00:00:00-07:00 The part at the end is the time zone offset
-07:00 in this example is for Mountain standard time. For Malaysia, it is +08:00.
The problem is the ‘+’ sign which is a special character in a URL. When passing that in a URL, + is converted into ‘ ‘, so in Malaysia, the API sees a start date of this: 2023-01-25T00:00:00 08:00
That is an invalid time/date string, so it gets ignored and ‘null’ is used. When most of the other API calls get null, they just get data from the earliest time in the DB (i.e. no starting date is used in the DB query). But the network status call works slightly differently; if no start/end date is specified, it doesn’t gather the ping data.
We didn’t see this in our testing because the testbed is always set to Mountain time. I’m sure this bug affects installations like in Romania as well—I suspect we just didn’t notice it until now.
Now I just have to figure out if I can replace the ‘+’ with the encoded value of ‘%2b’, or if there’s a better way to handle this.
The text was updated successfully, but these errors were encountered:
From an email I sent o James/Sam:
The text was updated successfully, but these errors were encountered: