@Temporal on Date field causes different format in the responses

[pavelfomin]

I'm using default json formatting configuration in my application.properties and expected dates to be returned as long timestamp values.

I've run into an issue using @TeMPOraL(TemporalType.DATE) annotation:

    @Temporal(TemporalType.DATE)
    @Column(name="dob")
    private Date dateOfBirth;

When I create a new entity using a PUT endpoint, the dob date is returned as a long timestamp as expected. However, a subsequent GET request returns json with date formatted as yyyy-MM-dd.

In addition, mockmvc test returns json with dob date formatted as long timestamp which masks the actual problem.

I'm using boot spring boot 1.4.0 and java 1.8.

Steps to reproduce:

• git clone --branch feature/date-temporal https://github.com/pavelfomin/spring-boot-rest-example.git
• mvn clean test
  • observe that both getPersonById and createPerson tests pass confirming that the dateOfBirth filed returned is a number
• start an application by running com.droidablebee.springboot.rest.Application
• create a person using the following curl command:

curl -X PUT --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{
  "dateOfBirth": "2016-10-17T18:09:52.540Z",
  "firstName": "james",
  "lastName": "bond",
"middleName": "007"
}' 'http://localhost:8080/v1/person'

• Observe the date format in the response as a long timestamp

{"id":1,"firstName":"james","lastName":"bond","middleName":"007","dateOfBirth":1476727792540}

• Find a person by id returned in the previous create response:

 curl -X GET --header 'Accept: application/json' 'http://localhost:8080/v1/person/1'

• Observe the date format in the response in a yyyy-MM-dd format:

{"id":1,"firstName":"james","lastName":"bond","middleName":"007","dateOfBirth":"2016-10-17"}

If I remove @Temporal then the date is returned as a timestamp. But it's also stored in the database with the time component. Adding @Temporal forces hibernate parameter binding for the date field to DATE instead of TIMESTAMP causing the the time truncation which is the desired behavior for the dob field.

[urvipatel21]

Add this to your config file and see if it works:

@Bean
    public Jackson2ObjectMapperBuilder jacksonBuilder() {
        Jackson2ObjectMapperBuilder builder = new Jackson2ObjectMapperBuilder();
        builder.featuresToEnable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);
        return builder;
    }

This will customize the jackson mapper implicitly used by spring boot.

[pavelfomin]

@urvipatel21, did you mean builder.featuresToEnable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS)? I need to have the timestamps returned. If I disable SerializationFeature.WRITE_DATES_AS_TIMESTAMPS then the date in the create response is returned as yyyy-MM-dd'T'HH:mm:ss.SSSZ. And enabling SerializationFeature.WRITE_DATES_AS_TIMESTAMPS did not solve the issue. It seems to be having the same effect as setting spring.jackson.serialization.write_dates_as_timestamps in application.properties. The date in the subsequent GET response is still returned as yyyy-MM-dd.

[pavelfomin]

Enabling or disabling SerializationFeature.WRITE_DATES_AS_TIMESTAMPS did not solve the issue. It's strange that an instance of the same class is rendered differently depending on which endpoint is invoked. Did you have a chance to try the sample app I've shared? Also, I'm getting concerned about using mockmvc for integration testing since I get different results during mockmvc run compare to running in the actual container.

[wilkinsona]

@pavelfomin Thanks for the sample. I've reproduced the behaviour you've described. Now to figure out what's going on…

[wilkinsona]

In one case the dateOfBirth is a java.util.Date and the other it's a java.sql.Date. When not written as a timestamp, the former is written by Jackson using whatever date format has been configured, while the latter is written by using the toString() method.

You may be interested in the Jackson Date Handling FAQ where it says "Please do NOT use java.sql.Date, ever!".

[pavelfomin]

Good one - sorry I've missed it! Turns out the date instance is getting changed to java.sql.Date by hibernate when personService.findOne(id) is called while application is running in the container.
I was confused because it did not change to java.sql.Date during the mvcmock test execution. The reason was that the hibernate was holding the created instance in the cache with java.util.Date still. Until entityManager.refresh(testPerson) was called, service method personService.findOne(id) was returning cached instance with java.util.Date that was not refreshed by hibernate yet. Once entityManager.refresh(testPerson) was added, the test case stared behaving the same way as during runtime in the container:

java.lang.AssertionError: JSON path "$.dateOfBirth"
Expected: is an instance of java.lang.Number
     but: "2016-10-18" is a java.lang.String

Also, if I remove @Temporal(TemporalType.DATE) then the instance type returned by hibernate changes to java.sql.Timestamp. I assume Jackson interpreted it correctly and this would explain why the long timestamp was returned w/out @Temporal(TemporalType.DATE).
Thanks for looking into this! Would you recommend using java.time.LocalDate instead of java.util.Date with spring data jpa backed up by hibernate? Or joda time?

[wilkinsona]

Would you recommend using java.time.LocalDate instead of java.util.Date with spring data jpa backed up by hibernate? Or joda time?

I'd only use Joda if you're stuck on Java 7. If java.time.* is available to you I'd just use that.

[pavelfomin]

One thing that still feels odd to me is that CrudRepository.save(S entity) does not return updated entity with java.sql.Date instance while findOne(ID id) returns an instance with java.sql.Date. Based on the java doc I expected CrudRepository.save(S entity) to return an updated instance containing java.sql.Date.

public interface CrudRepository<T, ID extends Serializable> extends Repository<T, ID> {

    /**
     * Saves a given entity. Use the returned instance for further operations as the save operation might have changed the
     * entity instance completely.
     * 
     * @param entity
     * @return the saved entity
     */
    <S extends T> S save(S entity);