swagger-api / swagger-api/swagger-codegen
JAVA: codegen Api client deserializes java.util.Date as Epoch second instead of Epoch Millisecond
Nobody has claimed this yet.
- Dominant language
- Mustache
- Stars
- 17.8k
- Forks
- 6k
- PR merge metrics
- No merged PRs in 30d
Description
Description
When deserializing the java.util.Date class, whatever json parser codegen is using expects the date to be an Epoch Second long but the rest of my project uses com.fasterxml.jackson which treats the Date class as an Epoch millisecond. Because of this, my controller serializes the Date into something like 1537919434406, but when the swagger generated client deserializes that long back into the Date object, the year is 50,000 something. Is there/can there be a way to specify this difference?
Swagger-codegen version
swagger-codegen-maven-plugin version: 2.3.1
swagger-annotations version: 1.5.15
Swagger declaration file content or url
This is obviously simplified but here is the definition that's causing trouble
"POJO": {
"type": "object",
"properties": {
"date": {
"type": "string",
"format": "date-time"
},
"name": {
"type": "string"
}
}
}
Command line used for generation
I'm using the swagger-codegen-maven-plugin
Steps to reproduce
Given POJO
{
"date": 1401606000000,
"name": "test"
}
jackson deserializes this json to
{
"date": "2014-06-01T07:00:00Z",
"name": "test"
}
but the generated client deserializes it to
{
"date": "+46719-02-25T15:43:20Z",
"name": "test"
}
I tried adjusting the setter to check is the value is greater than 20,000 and if so divide by 1000, but codegen ignores the setter
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the Java client generated from the supplied POJO schema and inspect its date-time deserialization path. Reproduce the issue with the provided JSON containing 1401606000000, then verify that the generated client interprets the value as the same 2014-06-01T07:00:00Z date as Jackson rather than a far-future date.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 50/100