Kratos PHP SDK: ISO 8601 encoded dates cannot be parsed as DateTime

[nohns]

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• This issue affects my Ory Cloud project.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Describe the bug

It would seem that the ISO 8601 encoded dates, sent in the /sessions/whoami JSON response, is in a format that the DateTime constructor in PHP cannot parse.

The SDK itself does not produce errors but the output is incorrect. The dates that are in a bad format and are deserialized as 1970-01-01 00:00:00, because the parsing fails silently.

I debugged the issue, and found that in my case some of the dates are parseable such as the "identity.created_at" field and others like "expires_at" are not. It would seem that PHP do not like the long miliseconds part of the date. Through trial and error, I figured it starts erroring when the millis part of the date is 9 digits or more. Anything below that is fine, and that is why it works with some of the dates.

Here is a slice of the session data:
{ "expires_at":"2021-11-18T20:46:52.404576263Z", "authenticated_at":"2021-11-17T20:46:52.438441763Z", ... "identity":{ ... "created_at":"2021-11-17T20:46:52.390087Z", "updated_at":"2021-11-17T20:46:52.390087Z" } }

Reproducing the bug

1. Running the ORY Kratos Quickstart
2. Try using the Kratos Client PHP SDK
3. Make a request to an endpoint and check the dates of the response models

Relevant log output

DateTime::__construct(): Failed to parse time string (2021-11-18T20:46:52.404576263Z) at position 0 (2): The timezone could not be found in the database

Relevant configuration

No response

Version

v0.8.0-alpha.3

On which operating system are you observing this issue?

macOS

In which environment are you deploying?

Docker Compose

Additional Context

No response

[aeneasr]

Oh damn, that's an interesting bug. Could it be related to your PHP version or does this affect all PHP versions? The format itself is complaint with the RFC afaik.

[NickUfer]

I will look into this later. PHP is built different... when it comes to standardized stuff that works in every other programming language it may not work in PHP. I already tried to fix this once in the generator but it seems there is more work to do: OpenAPITools/openapi-generator#7943

[nohns]

Im using PHP 7.4.25 for macOS 12.0.1 Monterey arm64 build. But as @NickUfer pointed out, it looks like there already was a fix made, but it does not seem like is enough :)

Here is a link to the code for deserialization of DateTimes in the generated code:
https://github.com/ory/kratos-client-php/blob/556c84db83d64a4447d3921c3a44e0c82966a9d6/lib/ObjectSerializer.php#L320

[NickUfer]

Okay, I tested it and this seems to be a problem in versions <= php7.4. It works without any problems with php8.0, even without the workaround. I think you should upgrade to php8.0 if it's possible... I also think there is no other fix for that except for cutting the string before creating a DateTime out of it, but such a solution would not be accepted in the generator project as it is too hacky.
If you can't upgrade to 8.0 and need that fix I'd suggest making a fork of the php client and implementing your own fix for that... or just write the fix straight into the vendor folder but that's really not the way to do things.

[kmherrmann]

Closing as it is 18 months old and relates to an old PHP version. please reopen if required.