You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by "Raman Gupta (JIRA)" <ji...@apache.org> on 2019/03/27 23:29:00 UTC
[jira] [Created] (AVRO-2360) Java 8 timestamp-millis /
timestamp-micros type inconsistency
Raman Gupta created AVRO-2360:
---------------------------------
Summary: Java 8 timestamp-millis / timestamp-micros type inconsistency
Key: AVRO-2360
URL: https://issues.apache.org/jira/browse/AVRO-2360
Project: Apache Avro
Issue Type: Bug
Components: java
Affects Versions: 1.9.0
Environment: JDK 11.0.2 on Linux
Followup on AVRO-2079.
Reporter: Raman Gupta
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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)