Response of reportsV20210630->getReport uses different date format

[KhorneHoly]

Call reportsV20210630->getReport.
This is a productive response provided as example:

{
    "createdTime": "2024-06-20T11:18:18+00:00",
    "dataEndTime": "2024-06-20T11:18:18+00:00",
    "dataStartTime": "2024-06-20T11:18:18+00:00",
    "marketplaceIds": [
        "A1PA6795UKMFR9"
    ],
    "processingEndTime": "2024-06-20T11:19:52+00:00",
    "processingStartTime": "2024-06-20T11:18:25+00:00",
    "processingStatus": "DONE",
    "reportDocumentId": "xxxxxxx",
    "reportId": "yyyyyyyy",
    "reportType": "GET_MERCHANT_LISTINGS_DATA"
}

The used date formats are different from the expected protected static string $datetimeFormat = 'Y-m-d\TH:i:s\Z'; format used in the Deserializes.php trait.

The return of this block

if (! class_exists($type) && ! interface_exists($type)) {
    throw new InvalidAttributeTypeException("Neither the Class nor Interface `$type` exists");
} elseif ($type == \DateTimeInterface::class) {
    if (strlen($value) === 10) {
        return DateTime::createFromFormat('Y-m-d', $value);
    } else {
        return DateTime::createFromFormat(static::$datetimeFormat, $value);
    }
}

is false, because the createFromFormat isn't the correct format for the value.

See screenshot attached:

Creating this issue because I don't know what the correct fix would be in the great scope of things.
Put it into a try-catch block and try another format if the first one fails?

[jlevers]

Thanks for reporting.

Let's do this: let's define a priority-sorted list of date/datetime format specifiers as a static attribute on Deserializes, and loop through them try/catching each one until one of them works or we run out of options, in which case we throw some sort of datetime in unknown format: $dateString exception.

That make sense?

[KhorneHoly]

Thanks for reporting.

Let's do this: let's define a priority-sorted list of date/datetime format specifiers as a static attribute on Deserializes, and loop through them try/catching each one until one of them works or we run out of options, in which case we throw some sort of datetime in unknown format: $dateString exception.

That make sense?

Sounds fine to me. Will open a PR as soon as I'm done. Might take until tomorrow noon though. Update: Opened a PR with a possible solution and a basic test.

[jlevers]

Fixed by #737 in v7.0.1.