You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After upgrading to springdoc-openapi-starter-webmvc-ui version 2.8.6, we noticed that OffsetDateTime values are no longer properly formatted in the Swagger UI. Instead of displaying the date-time in the expected format, we are now seeing Unix timestamp values.
Here is the relevant information for reproducing the issue:
In Swagger UI, the createdAt and updatedAt fields should display the OffsetDateTime in the following format:
"createdAt": "2022-12-02T14:14:32+01:00",
"updatedAt": "2022-12-02T14:14:41+01:00"
Actual Behavior (with version 2.8.6):
After the upgrade to springdoc-openapi-starter-webmvc-ui version 2.8.6, the createdAt and updatedAt fields are displayed as Unix timestamps, rather than formatted OffsetDateTime values. The Swagger UI shows:
"createdAt": 1669986872,
"updatedAt": 1669986881
Steps to Reproduce:
Upgrade springdoc-openapi-starter-webmvc-ui to version 2.8.6.
Define a DTO with OffsetDateTime fields as shown above.
Open the Swagger UI or check the OpenAPI documentation.
Observe that the createdAt and updatedAt fields are displayed as Unix timestamps instead of the expected formatted date-time string.
Additional Information:
The issue did not occur with version 2.8.5 of springdoc-openapi-starter-webmvc-ui, where the date-time fields were correctly formatted.
We are using the @DateTimeFormat(iso = DateTimeFormat.ISO.DATE_TIME) annotation for formatting the OffsetDateTime fields.
Suggested Solution:
It seems that the change in behavior might be related to how Springdoc OpenAPI is handling date-time formatting in version 2.8.6. We would expect that OffsetDateTime values should be automatically formatted as ISO 8601 date-time strings instead of Unix timestamps.
The text was updated successfully, but these errors were encountered:
Hi, looks like something that might be tied to the same issue as this? So might be that the fix would be to extend the fix that was done for that issue here?
Description:
After upgrading to springdoc-openapi-starter-webmvc-ui version 2.8.6, we noticed that OffsetDateTime values are no longer properly formatted in the Swagger UI. Instead of displaying the date-time in the expected format, we are now seeing Unix timestamp values.
Here is the relevant information for reproducing the issue:
pom.xml
org.springdoc springdoc-openapi-starter-webmvc-ui 2.8.6 Java DTO Class:import org.springframework.format.annotation.DateTimeFormat;
import java.time.OffsetDateTime;
import org.springframework.lang.Nullable;
public class ExampleDTO {
}
Expected Behavior (with version 2.8.5):
In Swagger UI, the createdAt and updatedAt fields should display the OffsetDateTime in the following format:
"createdAt": "2022-12-02T14:14:32+01:00",
"updatedAt": "2022-12-02T14:14:41+01:00"
Actual Behavior (with version 2.8.6):
After the upgrade to springdoc-openapi-starter-webmvc-ui version 2.8.6, the createdAt and updatedAt fields are displayed as Unix timestamps, rather than formatted OffsetDateTime values. The Swagger UI shows:
"createdAt": 1669986872,
"updatedAt": 1669986881
Steps to Reproduce:
Upgrade springdoc-openapi-starter-webmvc-ui to version 2.8.6.
Define a DTO with OffsetDateTime fields as shown above.
Open the Swagger UI or check the OpenAPI documentation.
Observe that the createdAt and updatedAt fields are displayed as Unix timestamps instead of the expected formatted date-time string.
Additional Information:
The issue did not occur with version 2.8.5 of springdoc-openapi-starter-webmvc-ui, where the date-time fields were correctly formatted.
We are using the @DateTimeFormat(iso = DateTimeFormat.ISO.DATE_TIME) annotation for formatting the OffsetDateTime fields.
Suggested Solution:
It seems that the change in behavior might be related to how Springdoc OpenAPI is handling date-time formatting in version 2.8.6. We would expect that OffsetDateTime values should be automatically formatted as ISO 8601 date-time strings instead of Unix timestamps.
The text was updated successfully, but these errors were encountered: