Hi @Codeh,

No, there was not deliberate change. What response and field are you referring to?

Also broke Kometa. Probably a bunch of other projects.

PR already accepted to fix it. https://github.com/Kometa-Team/TMDbAPIs/issues/199

|========================================= Critical Summary =========================================|
|                                                                                                    |
| Count | Message                                                                                    |
|=======|============================================================================================|
|     1 | time data '2023-03-16 15:19:41 UT' does not match format '%Y-%m-%dT%H:%M:%S'  

I'm gonna need the method and field(s) to be helpful.

Method: Get ?

Field: published_at

Old: "2024-11-18T04:47:37.000Z"

New: "2024-11-18 04:47:37 UTC"

Ok, I found the issue. There was a library that got upgraded and it changed how JSON timestamps were presented.

I've just deployed the fix so within the next ~8 hours, as items purge from the cache you'll start to see the corrected data.

Thanks.

Looks like it is still not fixed. Please take a look at the GitHub issue in the Jellyfin project.

It is fixed for me.

Not fixed for me (at least not for the created_at field):

"account_rating": {
        "created_at": "2024-12-08 23:42:58 UTC",
        "value": 7.0
      }

Srill not fixed on Windows

There are multiple reports of this issue persisting on our Discord server - is there anything further we can provide to help the team diagnose and resolve this?

I have been manually going through multiple API endpoint responses on the v3 API and have not found "T", "UT" or "UTC" suffixes on time stamps.

It is possible the ongoing issues are a result of some sort of caching being done by the individual projects, which is what was determined on the Kometa discussions. Clearing the cache file was recommended as a solution.

If there are ongoing issues being reported, then the full API call needs to be shared along with the field returning the data so that others can troubleshoot.

I found one more instance of Time objects not encoding correctly within the account methods. The fix for that is going up right now.

Working for me now