We are having an issue with ReadRowsByRange now that New Zealand has switched to DST. Testing recently we found that no profile data was being returned by the meter unless we wound back the start date/time prior to the DST change.
We have done a lot of testing to determine this problem, but it appears to be the DateTime, or GXDateTime passing into the ReadRowsByRange function.
If the start date/time is in standard time, the function returns data as expected, but if the start date/time is in daylight savings time, nothing is returned.
It appears that the end date/time (ST or DST) has no effect.
Our meters run in standard time, so we are using DateTimeOffset objects to provide date, time and time zone information.
The ReadRowsByRange function takes either DateTime, or GXDateTime objects. The translation of DateTimeOffset objects to these types reintroduces the state of daylight saving based on the state of the local host, so whatever we are doing to mitigate DST changes is overridden in the parameter passing to ReadRowsByRange.
Hopefully this is a clear description of the issue to you.
Do you have any feedback that you could provide to help up circumvent this issue?
Steve
As is always the way, after…
As is always the way, after much searching I find a resolution to my issue, but as long as it's fixed it's ok by me.
Ok, ReadRowsByRange and Daylight saving, the problem is surprisingly easy to fix, so great work Gurux for thinking ahead, just a bit light on documentation.
In the code snippet below, StartDate and EndDate can be DateTime, GXDataTime or DateTimeOffset. Whatever the format the (GXDateTime) start object will be polluted with the local machines time zone information, include DST.
In DST, .Status == DaylightSavingActive and ReadRowsByRange doesn't like it; well from my experience anyway.
Setting .Status = ClockStatus.Ok fixes the issue. Unlike MS datetime object, it's as simple as that. '.Skip = Deviation' has something to do with the absence of fields, and for completeness if I don't have these couple of lines I get meter access issues, no explanation, other than the message 'Other'.
GXDateTime start = new GXDateTime(StartDate);
GXDateTime end = new GXDateTime(EndDate);
start.Status = ClockStatus.Ok; // gets rid of DaylightSaving state
end.Status = ClockStatus.Ok; // gets rid of DaylightSaving state
start.Skip = DateTimeSkips.Deviation;
end.Skip = DateTimeSkips.Deviation;
commandBytes = _gxClient.ReadRowsByRange(_commandProfileGeneric, start, end);
Really hope this can help anyone else tearing their hair out for such a simple fix.
Hi, Different manufacturers…
Hi,
Different manufacturers have implemented DST differently.
With most of the meters it doesn't cause problems, but with some meters, it can be a real pain, especially if you are writing the new time to the meter.
Usually, you need to decrease time by one hour if you remove DTS, but I don't know should you do it, because I don't know what meter you are using.
Something like this:
GXDateTime start = new GXDateTime(StartDate.AddHours(-1));
start.Status = ClockStatus.Ok; // gets rid of DaylightSaving state
start.Skip = DateTimeSkips.Deviation;
This is done only when DST is active and not in normal time.
BR,
Mikko