Converting datetime to UTC and ISO format ends up with Z instead of +00:00

[houmie]

First Check

• I added a very descriptive title here.
• I used the GitHub search to find a similar question and didn't find it.
• I searched the FastAPI documentation, with the integrated search.
• I already searched in Google "How to X in FastAPI" and didn't find any information.
• I already read and followed all the tutorial in the docs and didn't find an answer.
• I already checked if it is not related to FastAPI but to Pydantic.
• I already checked if it is not related to FastAPI but to Swagger UI.
• I already checked if it is not related to FastAPI but to ReDoc.

Commit to Help

• I commit to help with one of those options 👆

Example Code

expiry_date = (device.expires_at.replace(tzinfo=pytz.UTC)).isoformat()
return {
        "expires_at": expiry_date
    }

Description

+00:00" is a valid ISO 8601 timezone designation for UTC. But this seems to have changed to Z. Is there a way to change this?

In fastapi==0.95.0 we created our ISO date like this and returned it as json:

expiry_date = (device.expires_at.replace(tzinfo=pytz.UTC)).isoformat()
return {
        "expires_at": expiry_date
    }

The unit test was expecting a dateformat like this:
2023-07-16T06:26:30.769459+00:00

assert response.json()["expires_at"] == date.strftime(
    "%Y-%m-%dT%H:%M:%S.%f+00:00"
)

But now with fastapi==0.100.0 the format has changed:
2023-07-16T06:26:30.769459Z

Is there a way to change this back to +00:00?

Many Thanks

Operating System

Linux

Operating System Details

MacOS and Linux

FastAPI Version

0.100.0

Python Version

3.11.4

Additional Context

No response

[jgould22]

The major change from FastAPI < 100 to FastAPI 100.0 is that Pydantic was upgraded to 2.0.

Recreating something like your sample below

from fastapi import FastAPI
from fastapi.testclient import TestClient
from datetime import datetime, date
import uvicorn
import pytz
import pytest

app = FastAPI()

@app.get("/")
async def root():
    test_date = datetime.now()
    test_date_tz = (datetime.now().replace(tzinfo=pytz.UTC)).isoformat()
    return {
        "date": test_date,
        "date_tz": test_date_tz
    }

client = TestClient(app)

def test_date():
    response = client.get("/")
    print( response.json())
    test_date = datetime.strptime(response.json()["date_tz"], "%Y-%m-%dT%H:%M:%S.%f+00:00").date()
    print(test_date)

{'date': '2023-07-16T12:04:18.439371', 'date_tz': '2023-07-16T12:04:18.439375+00:00'}

I do not get a Z in my response.

Perhaps it is related to the types that are not included in your sample code but we probably need a more complete piece of code to see what might be happening.

[jgould22]

Add this to your VerifyUserOut model

    @field_serializer('expires_at')
    def serialize_expires_at(self, expires_at: datetime, _info):
        return expires_at.strftime("%Y-%m-%dT%H:%M:%S.%f+00:00")

more info here https://docs.pydantic.dev/2.0/usage/serialization/#custom-serializers

[houmie]

Ah thank you. This looks more like a workaround to me though. What do you think? We didn't have to do this before, now I need to add this to the entire pydantic models, because datetime is suddenly formatted with a z at the end. It doesn't feel clean. I think it's fair to raise this as a bug. At least it can be looked into and rejected in worse case scenario. Thanks

[houmie]

@tiangolo What do you think? Do you agree this is a bug? It doesn't seem like a clean solution to me, compared to how FastAPI < 100 was working before in this regard. Thanks

[JavierSanchezCastro]

After reviewing the code, and as @jgould22 said, it's pydantic side.

Also, I see that there is an issue closed a few minutes ago: pydantic/pydantic#6735

Some other issues that report problems with datetime: pydantic/pydantic#7039 pydantic/pydantic#6592 pydantic/pydantic#6576

[houmie]

Thanks for the info. 👍🏼 You are right it's a pydantic issue. It seems indeed quite a bit of mess going by the number of reports about this. At least the workaround works on Fastapi, which is great. I'm keen to see how this develops and if they will be patching this or not.