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

Disabling WRITE_DATES_AS_TIMESTAMPS not working? #11

Closed
ddyangz opened this issue Feb 3, 2017 · 10 comments
Closed

Disabling WRITE_DATES_AS_TIMESTAMPS not working? #11

ddyangz opened this issue Feb 3, 2017 · 10 comments

Comments

@ddyangz
Copy link

ddyangz commented Feb 3, 2017

According to the /datetime/ summary, java.time.offsetDateTime objects should serialize out to ISO-8601 strings simply by disabling the SerializationFeature#WRITE_DATES_AS_TIMESTAMPS feature?

I've tried to do this in two different ways in the JacksonConfig class:

ObjectMapper mapper = new ObjectMapper()
            .registerModule(new ParameterNamesModule())
            .registerModule(new Jdk8Module())
            .registerModule(new JavaTimeModule())
            .configure(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS, false);
@Bean
@Primary
public ObjectMapper objectMapper(Jackson2ObjectMapperBuilder builder) {
        ObjectMapper objectMapper = builder.createXmlMapper(false).build();
        objectMapper
                .registerModule(new ParameterNamesModule())
                .registerModule(new Jdk8Module())
                .registerModule(new JavaTimeModule())
                .configure(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS, false);
        return objectMapper;
}

In both cases, serialized offsetDateTime objects continue to be printed in nanosecond timestamp format (i.e. "expiresOn":1486138656.853000000).

Only by actually declaring @jsonformat can I get them to print out in ISO-8601 string.

Is anyone else having this issue?

@bendem
Copy link

bendem commented Feb 6, 2017

That's most likely a problem coming from spring configuration.

  • Check there is no version conflict (pulling different version of jackson)
  • Use application properties to configure jackson (spring.jackson.serialization.write-dates-as-timestamps=false)
  • If the 2 solutions above do not work, start removing your @Enable___ annotations one by one, they sometime override your configuration.

@ddyangz
Copy link
Author

ddyangz commented Feb 6, 2017

Thanks.
#2 (adding spring.jackson.serialization.write-dates-as-timestamps=false to application properties) fixed it. I I guess spring jackson properties overloads the objectMapper of the Jackson Configuration.

@cowtowncoder
Copy link
Member

Assuming this gets resolved as described, as Spring config is out of Jackson's hands.
But if Jackson-side problems exist, may be reopened with a standalone test.

@Dienry
Copy link

Dienry commented Jan 3, 2018

Where do you put this in your code?

ObjectMapper mapper = new ObjectMapper()
.registerModule(new ParameterNamesModule())
.registerModule(new Jdk8Module())
.registerModule(new JavaTimeModule())
.configure(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS, false);

Thanks!

@bendem
Copy link

bendem commented Jan 3, 2018

Nowhere, you aren't supposed to instantiate your ObjectMapper yourself if you are using spring-boot. See my earlier answer.

@tibuurcio
Copy link

Hey guys, sorry for reopening this issue.

I've tried all of the solutions above to solve this problem but my Spring Controller keeps serializing LocalDateTime with it's properties instead of YYYY-MM-DD...

I think it could be a version conflict since I'm using other dependencies, but I don't know how to check for this. Can anyone shine a light on how can I do it?

@ddyangz
Copy link
Author

ddyangz commented Feb 27, 2018

Make sure you have this in your application.yml:

spring:
jackson:
serialization:
write-dates-as-timestamps: false

Keep the 3 noted in project title page in dependencies:
"com.fasterxml.jackson.module:jackson-module-parameter-names:{version}"
"com.fasterxml.jackson.datatype:jackson-datatype-jdk8:{version}"
"com.fasterxml.jackson.datatype:jackson-datatype-jsr310:{version}"

@cogito-abhijeet
Copy link

If you are using swagger with spring boot and your date is Date is always getting serialised as long, 
and SerializationFeature.WRITE_DATES_AS_TIMESTAMPS & spring.jackson.serialization.write-dates-as-timestamps=false
are not helping, below solution worked for me. Add it to your class annotated with @SpringBootApplication:

@Autowired
private RequestMappingHandlerAdapter handlerAdapter;

@EventListener
public void handleContextRefresh(ContextRefreshedEvent event) {
    handlerAdapter
            .getMessageConverters()
            .stream()
            .forEach(c -> {
                if (c instanceof MappingJackson2HttpMessageConverter) {
                    MappingJackson2HttpMessageConverter jsonMessageConverter = (MappingJackson2HttpMessageConverter) c;
                    ObjectMapper objectMapper = jsonMessageConverter.getObjectMapper();
                    objectMapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);
                }
            });
}

Actual issue: SerializationFeature.WRITE_DATES_AS_TIMESTAMPS value is not read from spring configuration file which need to be set false in order 
to covert long value while serialisation.

@kupci
Copy link
Member

kupci commented Sep 7, 2021

Actual issue: SerializationFeature.WRITE_DATES_AS_TIMESTAMPS value is not read from spring configuration

Should there be, or is there, an issue filed with Spring for this?

@MisterDurden
Copy link

MisterDurden commented Jun 2, 2022

@cogito-abhijeet
Hi, your solution worked but is there any way to achieve this without the EventListener annotation as we have certain restriction on startup time and I was looking for a way to configure this without using the EventListener?

Actual issue: SerializationFeature.WRITE_DATES_AS_TIMESTAMPS value is not read from spring configuration file which need to be set false in order 
to covert long value while serialisation.

Is this issue reported to Spring?

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

No branches or pull requests

8 participants