Allow OffsetDateTime to be parsed from a Double value

[shantanu-93]

In version 2.14.1, changes to handlling of OffsetDateTime type values was introduced to persist timezone. Earlier, OffsetDateTime type values were converted to a double type for storage and converted back to OffsetDateTime type on retrieval.

The earlier versions also were able to retrieve values stored as OffsetDateTime strings. Starting v2.14.1, during retrieval, the double type values are not parsed by the library and throw a DateTimeParseException.

exception: java.time.format.DateTimeParseException: Text '1657220671.920877' could not be parsed at index 0
	... 5 common frames omitted
Wrapped by: com.fasterxml.jackson.data.JsonMappingException: Text '1657220671.920877' could not be parsed at index 0 (through reference chain: com.company.org.project.service.api.v1_0.model.Schedule["triggerTime"])
	... 5 common frames omitted
Wrapped by: java.lang.IllegalArgumentException: The given string value: {"triggerTime": 1657220671.920877} cannot be transformed to Json object
	... 5 common frames omitted
Wrapped by: org.hibernate.HibernateException: java.lang.IllegalArgumentException: The given string value: {"triggerTime": 1657220671.920877} cannot be transformed to Json object
	... 5 common frames omitted
Wrapped by: org.springframework.orm.jpa.JpaSystemException: java.lang.IllegalArgumentException: The given string value: {"triggerTime": 1657220671.920877} cannot be transformed to Json object; nested exception is org.hibernate.HibernateException: java.lang.IllegalArgumentException: The given string value: {"triggerTime": 1657220671.920877} cannot be transformed to Json object
	at...

[vladmihalcea]

Try to investigate how it worked before, and send a Pull Request that supports that format too.

[vladmihalcea]

Before I merge that, I need to understand how did you manage to get an OffsetDateTime to be represented as 1657220671.920877?

I'm not aware of any Java Date/Time class whose toString() call would give you that.

Is that something that a custom library generates from an OffsetDateTime?

[shantanu-93]

As per my understanding, versions < 2.14.1 converted OffsetDateTime types to double value. Starting 2.14.1, the value started being stored as a readable date string. Does it have to do with this change?

[vladmihalcea]

@shantanu-93 No, according to Git history, the OffsetDateTimeDeserializer has always been like it is now.

Your change tries to parse the OffsetDateTime like this:

new Date((long) jsonParser.getDoubleValue() * 1000)

But, why? Is your JSON object containing epoch data?

In that case, you can supply your own ObjectMapper without having to change the framework logic. Check out this article for more details.

[shantanu-93]

@vladmihalcea, I think class OffsetDateTimeSerializer added in 2.14.1 changed how OffsetDateTime types are handled. I verified that up until 2.14.0, this type in a json field is converted to a double value in the types library at this point.

See this change.

[vladmihalcea]

@shantanu-93 I've just commented out this block:

public ObjectMapperWrapper() {
	this(new ObjectMapper()
		.findAndRegisterModules()
		/*.registerModule(
			new SimpleModule()
				.addSerializer(OffsetDateTime.class, OffsetDateTimeSerializer.INSTANCE)
				.addDeserializer(OffsetDateTime.class, OffsetDateTimeDeserializer.INSTANCE)
		)*/
	);
}

and, I run the GenericOffsetDateTimeJsonTest test, but it fails with:

Caused by: com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Java 8 date/time type `java.time.OffsetDateTime` not supported by default: add Module "com.fasterxml.jackson.datatype:jackson-datatype-jsr310" to enable handling (through reference chain: com.vladmihalcea.hibernate.type.json.generic.GenericOffsetDateTimeJsonTest$Location["rentedAt"])
	at com.fasterxml.jackson.databind.exc.InvalidDefinitionException.from(InvalidDefinitionException.java:77)
	at com.fasterxml.jackson.databind.SerializerProvider.reportBadDefinition(SerializerProvider.java:1276)
	at com.fasterxml.jackson.databind.ser.impl.UnsupportedTypeSerializer.serialize(UnsupportedTypeSerializer.java:35)
	at com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:728)
	at com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:770)
	at com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:178)

So, I'm not sure how it could have worked before. Try to investigate it, but I don't see how that double value could be generated.

[vladmihalcea]

After adding the dependency:

<dependency>
	<groupId>com.fasterxml.jackson.datatype</groupId>
	<artifactId>jackson-datatype-jsr310</artifactId>
	<version>${jackson-module-jaxb-annotation}</version>
</dependency>

I could, indeed, replicate the issue you mentioned.

DEBUG [Alice]: n.t.d.l.l.SLF4JQueryLoggingListener - Name:DATA_SOURCE_PROXY, Connection:4, Time:7, Success:True, Type:Prepared, Batch:False, QuerySize:1, BatchSize:0, Query:["insert into event (location, id) values (?, ?)"], Params:[({"country":"Romania","city":"Cluj-Napoca","reference":null,"rentedAt":1443682800.000000000}, 1)]

I'll integrate it for 2.17.1.

[vladmihalcea]

Fixed.