Understanding DateTime.Now and ISO8601 'Z' designation

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.

Solution

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.