[
https://issues.apache.org/jira/browse/BEAM-5530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17305597#comment-17305597
]
Matthew Ouyang commented on BEAM-5530:
--------------------------------------
Hello. In the spirit of Jeff's comments in the linked e-mail, would it be
possible to introduce a new datatype altogether in the Beam 2.x series for
nanosecond-precision java.time.Instant? One spot that would benefit right away
is BigQuery TIMESTAMP because it supports microseconds. I notice some work was
done on this as a part of BEAM-6017, can we reboot that and bring it to
completion?
In my project, I was presented a timestamp with microsecond precision. Since
JodaTime and therefore Beam only supports milliseconds, my only options were to
keep the full timestamp but cast it to string, or keep it as Beam DATETIME and
lose the microseconds. A nanosecond data type would have been nice because I
would have been able to keep it as a BQ TIMESTAMP with microseconds preserved;
yes I'm aware nanoseconds would have been dropped but I was willing to accept
that given BigQuery's current capabilities.
> Migrate to java.time lib instead of joda-time
> ---------------------------------------------
>
> Key: BEAM-5530
> URL: https://issues.apache.org/jira/browse/BEAM-5530
> Project: Beam
> Issue Type: Improvement
> Components: dependencies, sdk-java-core
> Reporter: Alexey Romanenko
> Priority: P3
> Labels: Clarified
> Fix For: 3.0.0
>
>
> Joda-time has been used till moving to Java 8. For now, these two time
> libraries are used together. It will make sense finally to move everywhere to
> only one lib - *java.time* - as a standard Java time library (see mail list
> discussion:
> [https://lists.apache.org/thread.html/b10f6f9daed44f5fa65e315a44b68b2f57c3e80225f5d549b84918af@%3Cdev.beam.apache.org%3E]).
>
> Since this migration will introduce breaking API changes, then we should
> address it to 3.0 release.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
