I am trying to get a handle on the interaction between DateTime.Now and ISO-8601 timezone designation for an API I am working on. An endpoint incorporates a timestamp as criteria for the interrogation of our data historian. The EndPoint returns the nearest previous 1/2 hour average for the datapoint requested and incorporates the following code:
If criteria.EndTime = "" Then
timeStamp = DateTime.Now
Else
timeStamp = CType(criteria.EndTime, DateTime)
End If
The body of the post accepts the following json:
{
"Interval": "30m",
"StartTime": "",
"EndTime": "2022-04-21T00:45:00Z",
"TagList": "PointName",
"Delim":",",
"PointSource": "P",
"ServerName": "PIServer"
}
Where the EndTime is the parameter picked up by the endpoint. We are currently in British Summer Time i.e. DST is UTC 01:00. With the above criteria the data I get back is timestamped as follows:
[
{
"PointName": "PointName",
"TimeStamp": "21/04/2022 01:30:00",
"Value": "-2.3607"
},
{
"PointName": "PointName",
"TimeStamp": "21/04/2022 01:30:00",
"Value": "-2.6333"
}
]
As you can see the data returned is for 01:30 rather than the 00:30 that is expected. If I leave the 'Z' designation out of the criteria then I get the correct content returned. Can someone explain what is happening here please.
CodePudding user response:
Let's assume the client sent UTC based time (yours is) and the server responds in UTC time (it does not). As described, ...T00:30:00Z
(00:30:00 UTC) is the correct answer to your input of ...T00:45:00Z
based on what you said the endpoint does.
Now let's say the server responds in BST (which, it seems to) to the same UTC based client request. Then ...T01:30:00
(no time zone designation, assumed to be BST) is the correct answer for your input because 00:30:00 UTC is equivalent to 01:30:00 BST, which is the correct result given the server's rules.
I think you've missed the fact that the server appears to always be returning BST (perhaps that's local to the server) without a time zone designation (i.e. you could argue it should be returning T01:30:00 1:00
)
It appears that if you send UTC (or any other time with time zone info), you get a BST response with no time zone designation, and if you send a time with no time zone info, the server assumes you're sending BST, and still returns BST.
So, when you remove the Z
from your request, you get what you think is the wrong answer, but isn't because T00:45:00
(aka 00:45:00 assumed BST) the server will respond with T00:30:00
(aka 00:30:00 assumed BST).
I suspect if you sent T00:45:00 1:00
you'd get back T00:00:00 1:00
, but if you don't (i.e. no to zime zone info), then it might be a server bug. You could test this by sending T00:45:00 2:00
and seeing if you get back T00:00:00 2:00
or not.