[jira] [Commented] (AVRO-2360) Java 8 timestamp-millis / timestamp-micros type inconsistency
[ https://issues.apache.org/jira/browse/AVRO-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804921#comment-16804921 ] Fokko Driesprong commented on AVRO-2360: Thanks for giving 1.9-SNAPSHOT a try. We need to get this fixed before we can ship it. > 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 >Reporter: Raman Gupta >Assignee: Daniel Kulp >Priority: Blocker > Fix For: 1.9.0 > > > 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. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AVRO-2360) Java 8 timestamp-millis / timestamp-micros type inconsistency
[ https://issues.apache.org/jira/browse/AVRO-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804203#comment-16804203 ] Raman Gupta commented on AVRO-2360: --- Awesome, thanks for the quick resolution to both problems. Looking forward to the 1.9.0 release. > 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 >Reporter: Raman Gupta >Assignee: Daniel Kulp >Priority: Blocker > Fix For: 1.9.0 > > > 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. -- This message was sent by Atlassian JIRA (v7.6.3#76005)