[AVRO-2360] Java 8 timestamp-millis / timestamp-micros type inconsistency

• Type: Bug
• Status: Resolved
• Priority: Blocker
• Resolution: Fixed
• Affects Version/s: 1.9.0
• Fix Version/s: 1.9.0
• Component/s: java

Environment

JDK 11.0.2 on Linux

• Hadoop Flags: Incompatible change
• Assignee: Daniel Kulp
• Reporter: Raman Gupta
• Created: 27/Mar/19 23:28
• Updated: 29/Mar/19 12:46
• Resolved: 28/Mar/19 18:02

Description

I am trying the new JSR 310 date/time types with a snapshot of 1.9.0.

I see what seems to be an inconsistency. If I generate my code with a logical type of "timestamp-millis", then the code is generated with `Instant`, as expected. However, on JDK11 on Linux, if I do `Instant.now()` the Instant value created contains microseconds. When setting this Instant on an instance of the generated Avro SpecificRecord, I am unable to round-trip the data:

Before serialization to bytes:

System.out.println(mySpecificRecord.tsMillis()) // 2019-03-27T23:16:09.665308Z

After serializing to bytes, and then back into a specific record the microseconds are now truncated:

System.out.println(mySpecificRecord.tsMillis()) // 2019-03-27T23:16:09.665Z

I believe the compiler should generate a class that truncates the microseconds at `setter` time for "timestamp-millis", so that the value before serialization, and after deserialization, are the same. This can be done with a call to the method `truncatedTo(ChronoUnit.MILLIS)`.

Another, possibly related, oddity is that the "timestamp-micros" type generates a class with `long` as the type of the field. Since Instant can support both milli and micro-second precision, I don't see the reason for this behavior.

Followup on AVRO-2079.

Issue Links

• is related to: AVRO-2289 Support Java 11