coverage: 79.05% (-0.01%) from 79.063% when pulling c779dc2 on kayrus:share-transfer into 44d55f0 on gophercloud:master.

@mandre @pierreprinetti ready for review

You're right in all comments :) Thanks. As for the UTC offset, for some reason I cannot access debug logs for intermediate push :\ I don't have this API locally, therefore I rely on API reference and CI tests :)

According to debug logs the time format is fine:

2023/06/21 07:48:00 [DEBUG] OpenStack Response Body: {
  "transfer": {
    "accepted": false,
    "auth_key": "4fbbb3ba15e6549e",
    "created_at": "2023-06-21T07:48:00.589548",
    "destination_project_id": null,
    "expires_at": "2023-06-21T07:53:00.587670",
    "id": "787da824-1b89-46f5-9ec7-e0b5afa2f28c",
    "links": [
      {
        "href": "http://10.1.120.0/share/v2/share-transfer/787da824-1b89-46f5-9ec7-e0b5afa2f28c",
        "rel": "self"
      },
      {
        "href": "http://10.1.120.0/share/share-transfer/787da824-1b89-46f5-9ec7-e0b5afa2f28c",
        "rel": "bookmark"
      }
    ],
    "name": "123",
    "resource_id": "dbae4463-25f3-42c3-9b18-46bc29ff733d",
    "resource_type": "share",    
    "source_project_id": "98df2063d7a8467eadc137dd4c5f4ca7"
  }
}

Yep, because our devstack returns the date without the UTC offset, which is why we're able to parse it. The ±hh:mm part is optional in the ISO 8601 format. It would break if manila included it in it's responses.
It's not a big deal, as far as I know nobody reported issues, so that's probably not common at all in the wild, or perhaps just a documentation problem.

@mandre BTW, does it make sense to turn on the OS_DEBUG=true for all tests?

@mandre BTW, does it make sense to turn on the OS_DEBUG=true for all tests?

I'm afraid this is going to generate too much logs. The errors are generally obvious when we debug a CI job. We can always manually add it when needed, like you did.