[
https://issues.apache.org/jira/browse/AVRO-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
