[QUESTION] [FEATURE?] Why do the generated docs use Z-terminated ISO strings when python doesn't?

First check

[x] I used the GitHub search to find a similar issue and didn’t find it. [x] I already searched in Google “How to X in FastAPI” and didn’t find any information. [x] I searched the FastAPI documentation, with the integrated search.

Description

So, first of all, I know that pydantic is smart and accepts strings ending in Z for datetimes. I am thankful that pydantic follows ISO guidelines even though python’s standard datetime library rejects them.

But It feels weird that the generated docs use this approach rather than the default expected by python (which is, often, to treat a naive datetime as UTC, but otherwise to append +00:00.

It’s noteworthy that even when pydantic serializes back to json, it uses the +00:00.

Additionally, given that we can’t trivially (by type hints) tell the pydantic model to be based on a specific timezone, it feels like the generated documentation is misleading, suggesting to users that they should be using a timezone-aware string when in fact, there’s no guarantee that the code is intended to handle a timezone aware string.

I think I would expect the default behavior to specify simply naive datetime iso strings and have to do something additional to make the documentation suggest tz aware strings, rather than the other way around.

Additional context

In [10]: x = Thing(a="2020-01-01T00:00Z")

In [11]: x.json()
Out[11]: '{"a": "2020-01-01T00:00:00+00:00"}'

In [12]: x = Thing(a="2020-01-01T00:00:00")

In [13]: x.json()
Out[13]: '{"a": "2020-01-01T00:00:00"}'

[dcrowe]

I’ve found two ways to make FastAPI produce ISO8601 datetimes:

datetime.now(timezone.utc)
time.time()

[dorinclisu]

This issue is not solved, the problem is the fastapi docs still state that datetime will be seriallized to ISO 8601. https://fastapi.tiangolo.com/tutorial/extra-data-types/ Which is a big lie as @wozniakty pointed out.