Why do the generated docs use Z-terminated ISO strings when python doesn't? #7693
-
First check[x] I used the GitHub search to find a similar issue and didn't find it. DescriptionSo, 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 It's noteworthy that even when pydantic serializes back to json, it uses the 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"}' |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments 1 reply
-
|
The OpenAPI spec says that the From what I can tell, it really is more of an interface issue (OpenAPI implicitly requires date-time strings to be timezone-aware) combined with a defaut value issue (most renderers just use the current UTC datetime as example values for those strings unless you specify a different example). Pydantic just happens to be a bit more permissive in that regard. |
Beta Was this translation helpful? Give feedback.
-
|
Yep, as @sm-Fifteen says ☝️ |
Beta Was this translation helpful? Give feedback.
-
|
Assuming the original issue was solved, it will be automatically closed now. But feel free to add more comments or create new issues. |
Beta Was this translation helpful? Give feedback.
-
|
This issue is not solved, the problem is the fastapi docs still state that |
Beta Was this translation helpful? Give feedback.
-
|
I've found two ways to make FastAPI produce ISO8601 datetimes: |
Beta Was this translation helpful? Give feedback.
-
It returns datetime with Zulu at the end Same with |
Beta Was this translation helpful? Give feedback.
-
|
still actual |
Beta Was this translation helpful? Give feedback.
The OpenAPI spec says that the
date-timeformat (which is what FastAPI and pydantic convert python datetime objects into) only needs to be an RFC3339-compliant string (not ISO8601, but a subset), with no restriction of the timezone format, so bothZand+00:00need to be supported. I forget how Pydantic handles it, but RFC3339 does mandate that valid strings have a timezone offset specifier, as raised in OAI/OpenAPI-Specification#1498.From what I can tell, it really is more of an interface issue (OpenAPI implicitly requires date-time strings to be timezone-aware) combined with a defaut value issue (most renderers just use the current UTC datetime as example values for those strings unles…