Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect date format when in response object #2680

Closed
ghsatpute opened this issue Feb 22, 2018 · 6 comments
Closed

Incorrect date format when in response object #2680

ghsatpute opened this issue Feb 22, 2018 · 6 comments
Labels

Comments

@ghsatpute
Copy link

Q A
Bug or feature request? Bug
Which Swagger-Core version? 2
Which Java version? 8.0

Demonstration API definition

From my API I'm returning a DTO which looks like below

class ResponseDTO  {
     Date CreatedOn;
     Date ModifiedOn;
}

If I look on the swagger UI, I see this
image

Here, the actual response sent by the server is in long format (number of milliseconds since 1970). But the swagger is showing Date format as "ModifiedOn": "2018-02-20T17:23:58.907Z". Which is kind of misleading.

Expected Behavior

"ModifiedOn": "1519147559685"
Or something like this

@webron
Copy link
Contributor

webron commented Feb 22, 2018

That's what 'date' is defined as. If you need it to be in a long format, you need to specify it using the annotations.

@webron webron added the Support label Feb 22, 2018
@ghsatpute
Copy link
Author

ghsatpute commented Feb 26, 2018

@webron, I tried that using writing annotations

	@ApiModelProperty(value = "Start time of launch", required=true, dataType = "long")
	private Date createdOn;

I'm getting the same output as above.

Am I missing something?

@webron
Copy link
Contributor

webron commented Feb 26, 2018

Which version of swagger-core do you use?

@thiagoarrais
Copy link

Bump: this is also showing up in the java-jersey2-resourceinit sample (2.0 branch).

Steps to reproduce

  1. Run said sample as per instructions
  2. Go to Swagger-UI at http://localhost:8002
  3. Check example value for route GET /sample/store/order/{orderId}:

Captura de tela de 2019-05-29 15-27-23

  1. Check that schema says that the type for shipDate is a date-time string:

Captura de tela de 2019-05-29 15-27-37

  1. Make a sample request for order 1
  2. The API returns a long value for shipDate, breaking spec:

Captura de tela de 2019-05-29 15-28-16

Suggested fix

In my opinion, either java.util.Date should be mapped to int64 on the spec or it should somehow be output in RFC 3339 format to be spec compatible.

frantuma added a commit to swagger-api/swagger-samples that referenced this issue Aug 1, 2019
frantuma added a commit to swagger-api/swagger-samples that referenced this issue Aug 1, 2019
@frantuma
Copy link
Member

frantuma commented Aug 1, 2019

in Swagger Core 2.x there are a few alternatives (sample has been updated with option 3):

  1. annotate your property with @Schema(type = "integer", format = "int64")
  2. customize swagger by adding the following in any bootstrap code
PrimitiveType.customExcludedClasses().add(Date.class.getName());
PrimitiveType.customClasses().put(Date.class.getName(), PrimitiveType.LONG);
  1. depending on the environment, configure its serialization of requests and responses not to use timestamps, e.g. in jersey2:
@Provider
    public class ObjectMapperContextResolver implements ContextResolver<ObjectMapper> {

        private final ObjectMapper mapper;

        public ObjectMapperContextResolver() {
            this.mapper = createObjectMapper();
        }

        @Override
        public ObjectMapper getContext(Class<?> type) {
            return mapper;
        }

        private ObjectMapper createObjectMapper() {
            ObjectMapper mapper = new ObjectMapper();
            mapper.configure(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS, false);
            return mapper;
        }
    }
register(new ObjectMapperContextResolver());

closing ticket, please reopen if you're still experiencing issues

@frantuma frantuma closed this as completed Aug 1, 2019
@thiagoarrais
Copy link

Thanks! Please consider making that default behaviour.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants