Timestamp zone and asset datapoint API

[pacogam]

Hello,
I’m collecting data from several Shellies through MQTT and have now retrieved it through the API. I’ve previously seen in the OR graph that the timestamps are in local time. In PostgreSQL they are also like this (timestamp without time zone). Is that because the collected data was in local time? I mean, they are never internally converted to UTC before saving them in the database? I don’t know if that will cause a problem when the time change occurs.
Anyway, the point is that if I use the API /asset/datapoint/{assetId}/{attributeName} using the request body

{
	"fromTime": "2024-05-15T14:24:00",
	"toTime": "2024-05-15T14:25:00",
	"type": "string"
}

and the format suggested in the documentation:

{
	"fromTime": "2024-05-15T14:24:00.000Z",
	"toTime": "2024-05-15T14:25:00.000Z",
	"type": "string"
}

the result is the same, with timestamps in local time between 14:24:00 and 14:25:00. Not what I would expect if I use UTC format. Is this a bug or is it just me?

Thanks

[martin.peeters]

Hi!

I’m always confused about timezones myself, so excuse me if this is not useful at all;

.
The AssetDatapointQuery body within the asset datapoint API accepts either

• a java.time.LocalDateTime as the “fromTime” parameter,
• or the amount of milliseconds from epoch using the “fromTimestamp” parameter.

We use the last one most often within the UI, haven’t used the “fromTime” in a while.

[pacogam]

Hi Martin, thanks for your response. I’m used to use the ISO 8601 format for timestamps. If you haven’t used the “fromTime” parameter for a long time, I must understand that it’s a bug, fortunately not a serious one. But yes, this is an issue that often lends itself to confusion, especially when you have pilots in different time zones at the same time and they work on local time.

BR

[martin.peeters]

Created an issue for this on our GitHub repository;

DatapointQuery: investigate fromTime and toTime properties

Just so we can keep track of it

No clue whether we’re able to pick it up any time soon…
But feel free to investigate and/or comment on it, so it makes the process easier.
(or open up a PR if you found the time to adjust / fix it haha)