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
When GO sends the metering data and the pS value is in Estonian format the way, that it's the missing hour from the spring daylight saving time change, that doesn't exist (because of 23h day), then the System doesn't respond with error, but processes the data, stores it to pS 00:00 and even distributes the wrong data to OS.
Steps to reproduce
NB! I don't know, how to reproduce that issue in the DEV environment. It was reported by the OS from Live. But it seems, that you have to send metering data message, that contains pS value "2024-03-31T03:00:00+03:00" (this value cannot be translated to UTC)
Expected result
System identifies the error and responds accordingly.
Actual Result
System processes the data and if I'm not mistaken, then stores the value to 00:00 hour.
System creates DD message, that contains "pS": "2024-03-31T03:00+03:00":
Problem
When GO sends the metering data and the pS value is in Estonian format the way, that it's the missing hour from the spring daylight saving time change, that doesn't exist (because of 23h day), then the System doesn't respond with error, but processes the data, stores it to pS 00:00 and even distributes the wrong data to OS.
Steps to reproduce
NB! I don't know, how to reproduce that issue in the DEV environment. It was reported by the OS from Live. But it seems, that you have to send metering data message, that contains pS value "2024-03-31T03:00:00+03:00" (this value cannot be translated to UTC)
Expected result
System identifies the error and responds accordingly.
Actual Result
Impact (If known)
OS-s cannot process the DD message, because they try to parse the value "2024-03-31T03:00+03:00"
Work-a-round
Use only UTC, but we cannot force that.
The text was updated successfully, but these errors were encountered: