I am struggling a bit to get a DateTime filter going when using GET/TrendSamples.
What should the format be for this? I have tried a bunch of different formats however it keeps returning all the latest entries.
AlarmEvent for the referenced Alarm.
Id of the Trend which TrendSample are to be returned for. This parameter is not optional.
TrendSample with this State value.
TrendSample with SampleDate which is on or after this value.
TrendSample with SampleDate which is before this value.
will be returned in this order. SampleDateAscending by default.
TrendSample that should be returned. 200 by default.
TrendSample that should be skipped before items are returned. 0 by default.
Any valid date format will work however, if your values do not include time zone offset or are not in UTC format, then the resulting predicate may not be what you intended.
Also, sampledOnOrAfter and sampledBefore can be used separately or in tandem. So each side of the following expression may be omitted if the supplied value is null.
TrendSample.SampleDate>= sampledOnOrAfter && TrendSample.SampleDate< sampledBefore
Some sample requests would be helpful in determining where the issue may be. If you are using the SOAP provider, you should enable "Ews Consume" filtering (Debug level) and you will see how your REST calls are translated into an EWS SOAP request.
Ok Using the time format 2017-05-09T22:00:07Z did the trick. However I have a concern on how Smart Connector is handling the timestamps on the samples.
In South Africa We are GMT+2. When I run the GET/TrendSamples request it reduces the actual timestamp by 2 hours and what makes it worse is if I have a midnight sample on 2017-05-10, it incorrectly gives me a timestamp of 2017-05-09 22:00PM.
Of course it is using UTC but there must be a way to get around this:
All values returned by the REST Gateway should be in UTC. With the SoapEwsRestProvider, SmartConnector is passing the values through from the server since EWS mandates that the values returned are in UTC.
Before we can determine if this might be a serialization issue in the REST layer, we need to see what SBO is returning over SOAP.
Do you have any log captures with that information? If you enable "Ews Consume" logging filter at Debug level you will see the SOAP request/response pairs. If the value there is correct, but the value returned over REST is not, then we may have a serialization issue.