[jira] [Commented] (BEAM-5530) Migrate to java.time lib instead of joda-time

2022-06-03 Thread Kenneth Knowles (Jira)


[ 
https://issues.apache.org/jira/browse/BEAM-5530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17547454#comment-17547454
 ] 

Kenneth Knowles commented on BEAM-5530:
---

This issue has been migrated to https://github.com/apache/beam/issues/19215

> 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.20.7#820007)


[jira] [Commented] (BEAM-5530) Migrate to java.time lib instead of joda-time

2021-06-13 Thread Anant Damle (Jira)


[ 
https://issues.apache.org/jira/browse/BEAM-5530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17362731#comment-17362731
 ] 

Anant Damle commented on BEAM-5530:
---

There are now some side-effects especially across different OSes: Joda daysDiff
{code:java}
@Test
public void jodaDaysDiff() {
  var days = org.joda.time.Days.daysBetween(org.joda.time.Instant.EPOCH, 
org.joda.time.Instant.parse("2002-07-13")).getDays();

  // Linux: pass
  // MacOS: fail // actual = 11881
  assertThat(days).isEqualTo(11880);
}

@Test
public void javaTimeDaysDiff() {
  var date = java.time.Instant.parse("2002-07-13T00:00:00Z");
  var days = 
java.time.temporal.ChronoUnit.DAYS.between(java.time.Instant.EPOCH, date);

  // Linux: pass
  // MacOS: pass
  assertThat(days).isEqualTo(11881);
}
{code}

> 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)


[jira] [Commented] (BEAM-5530) Migrate to java.time lib instead of joda-time

2021-03-20 Thread Matthew Ouyang (Jira)


[ 
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)


[jira] [Commented] (BEAM-5530) Migrate to java.time lib instead of joda-time

2020-06-16 Thread Beam JIRA Bot (Jira)


[ 
https://issues.apache.org/jira/browse/BEAM-5530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17137573#comment-17137573
 ] 

Beam JIRA Bot commented on BEAM-5530:
-

This issue was marked "stale-P2" and has not received a public comment in 14 
days. It is now automatically moved to P3. If you are still affected by it, you 
can comment and move it back to P2.

> 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
> 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)


[jira] [Commented] (BEAM-5530) Migrate to java.time lib instead of joda-time

2020-06-01 Thread Beam JIRA Bot (Jira)


[ 
https://issues.apache.org/jira/browse/BEAM-5530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17123129#comment-17123129
 ] 

Beam JIRA Bot commented on BEAM-5530:
-

This issue is P2 but has been unassigned without any comment for 60 days so it 
has been labeled "stale-P2". If this issue is still affecting you, we care! 
Please comment and remove the label. Otherwise, in 14 days the issue will be 
moved to P3.

Please see https://beam.apache.org/contribute/jira-priorities/ for a detailed 
explanation of what these priorities mean.


> 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: P2
>  Labels: stale-P2
> 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)


[jira] [Commented] (BEAM-5530) Migrate to java.time lib instead of joda-time

2020-03-05 Thread Luke Cwik (Jira)


[ 
https://issues.apache.org/jira/browse/BEAM-5530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17052387#comment-17052387
 ] 

Luke Cwik commented on BEAM-5530:
-

We don't need to map to joda time internally, we just have to ensure the 
encoding hasn't changed which means that we have to maintain millis only level 
of time precision and report an error if the timestamp requires finer 
granularity.

> 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: Major
> 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)


[jira] [Commented] (BEAM-5530) Migrate to java.time lib instead of joda-time

2020-03-05 Thread Jira


[ 
https://issues.apache.org/jira/browse/BEAM-5530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17052158#comment-17052158
 ] 

Ismaël Mejía commented on BEAM-5530:


We can start to provide alternative methods for all of time uses of 
`sdks/java/core` based on java time as a path towards removal. This way we can 
then then start deprecating the Joda Time methods. WDYT ?
Extra comment I suppose we should map then internally towards Joda to avoid 
breaking backwards compatibility for the Coders, is this correct [~lcwik] or 
can we avoid that part?

> 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: Major
> 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)


[jira] [Commented] (BEAM-5530) Migrate to java.time lib instead of joda-time

2019-09-05 Thread Luke Cwik (Jira)


[ 
https://issues.apache.org/jira/browse/BEAM-5530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16923892#comment-16923892
 ] 

Luke Cwik commented on BEAM-5530:
-

One advantage with jodatime is that the TZDB is typically updated more often 
and you don't have to wait for a JVM release or muck with the JVM installation 
to get an update TZDB.

Once custom containers are used for the Java SDK everywhere, this point will be 
moot because then anybody will be able to roll their own container containing 
an updated TZDB,

> 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
>Reporter: Alexey Romanenko
>Priority: Major
> 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.2#803003)