[jira] [Commented] (GROOVY-7964) TimeCategory incorrectly counts days difference between two dates
[
https://issues.apache.org/jira/browse/GROOVY-7964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15573436#comment-15573436
]
Paul King commented on GROOVY-7964:
---
Well, it is either a bug or different assumptions about time zones.
> TimeCategory incorrectly counts days difference between two dates
> -
>
> Key: GROOVY-7964
> URL: https://issues.apache.org/jira/browse/GROOVY-7964
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.4.7
> Environment: Windows 10 x86_64, Oracle Java 1.8.0.102 x86_64
>Reporter: Los Pejos
> Labels: timecategory
> Attachments: DatesDiff.groovy
>
>
> TimeCategory incorrectly counts days difference between two dates.
> Exhibit (Groovy code):
> {code}
> #!/usr/bin/env groovy
> @Grab(group='joda-time', module='joda-time', version='2.9.4+')
> import java.io.BufferedReader
> import java.io.IOException
> import java.io.InputStreamReader
> import java.time.LocalDate
> import java.time.format.DateTimeFormatter
> import java.time.temporal.ChronoUnit
> import groovy.time.TimeCategory
> String date1 = '2016-03-22'
> String date2 = '2016-03-29'
> String fmt = '-MM-dd'
> // Java 8 ChronoUnit:
> DateTimeFormatter formatter = DateTimeFormatter.ofPattern(fmt)
> //LocalDate firstDate = LocalDate.parse(date1, formatter)
> //LocalDate secondDate = LocalDate.parse(date2, formatter)
> long days = ChronoUnit.DAYS.between(
> LocalDate.parse(date1, formatter),
> LocalDate.parse(date2, formatter)
> )
> println "Java 8 ChronoUnit: Dates between $date1 and $date2 : $days"
> // Groovy TimeCategory/Date:
> use (TimeCategory) {
> def d = (Date.parse(fmt, date2) - Date.parse(fmt, date1)).days
> println "Groovy TimeCategory/Date: Dates between $date1 and $date2 : $d"
> }
> // Joda Time:
> // LocalDate fromDateFields(Date date)
> // Date.parse('-MM-dd', dlf.@dldpf.toString())
> days = org.joda.time.Days.daysBetween(
> org.joda.time.LocalDate.fromDateFields(Date.parse(fmt,date1)),
> org.joda.time.LocalDate.fromDateFields(Date.parse(fmt,date2))
> ).getDays()
> println "Joda Time: Dates between $date1 and $date2 : $days"
> {code}
> Current Output:
> {noformat}
> $ groovy DatesDiff.groovy
> Java 8 ChronoUnit: Dates between 2016-03-22 and 2016-03-29 : 7
> Groovy TimeCategory/Date: Dates between 2016-03-22 and 2016-03-29 : 6
> Joda Time: Dates between 2016-03-22 and 2016-03-29 : 7
> {noformat}
> Expected Output:
> {noformat}
> $ groovy DatesDiff.groovy
> Java 8 ChronoUnit: Dates between 2016-03-22 and 2016-03-29 : 7
> Groovy TimeCategory/Date: Dates between 2016-03-22 and 2016-03-29 : 7
> Joda Time: Dates between 2016-03-22 and 2016-03-29 : 7
> {noformat}
> Resume: notice the difference in "Groovy TimeCategory/Date" line.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GROOVY-7964) TimeCategory incorrectly counts days difference between two dates
[
https://issues.apache.org/jira/browse/GROOVY-7964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Los Pejos updated GROOVY-7964:
--
Attachment: (was: DatesDiff.groovy)
> TimeCategory incorrectly counts days difference between two dates
> -
>
> Key: GROOVY-7964
> URL: https://issues.apache.org/jira/browse/GROOVY-7964
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.4.7
> Environment: Windows 10 x86_64, Oracle Java 1.8.0.102 x86_64
>Reporter: Los Pejos
> Labels: timecategory
> Attachments: DatesDiff.groovy
>
>
> TimeCategory incorrectly counts days difference between two dates.
> Exhibit (Groovy code):
> {code}
> #!/usr/bin/env groovy
> @Grab(group='joda-time', module='joda-time', version='2.9.4+')
> import java.io.BufferedReader
> import java.io.IOException
> import java.io.InputStreamReader
> import java.time.LocalDate
> import java.time.format.DateTimeFormatter
> import java.time.temporal.ChronoUnit
> import groovy.time.TimeCategory
> String date1 = '2016-03-22'
> String date2 = '2016-03-29'
> String fmt = '-MM-dd'
> // Java 8 ChronoUnit:
> DateTimeFormatter formatter = DateTimeFormatter.ofPattern(fmt)
> //LocalDate firstDate = LocalDate.parse(date1, formatter)
> //LocalDate secondDate = LocalDate.parse(date2, formatter)
> long days = ChronoUnit.DAYS.between(
> LocalDate.parse(date1, formatter),
> LocalDate.parse(date2, formatter)
> )
> println "Java 8 ChronoUnit: Dates between $date1 and $date2 : $days"
> // Groovy TimeCategory/Date:
> use (TimeCategory) {
> def d = (Date.parse(fmt, date2) - Date.parse(fmt, date1)).days
> println "Groovy TimeCategory/Date: Dates between $date1 and $date2 : $d"
> }
> // Joda Time:
> // LocalDate fromDateFields(Date date)
> // Date.parse('-MM-dd', dlf.@dldpf.toString())
> days = org.joda.time.Days.daysBetween(
> org.joda.time.LocalDate.fromDateFields(Date.parse(fmt,date1)),
> org.joda.time.LocalDate.fromDateFields(Date.parse(fmt,date2))
> ).getDays()
> println "Joda Time: Dates between $date1 and $date2 : $days"
> {code}
> Current Output:
> {noformat}
> $ groovy DatesDiff.groovy
> Java 8 ChronoUnit: Dates between 2016-03-22 and 2016-03-29 : 7
> Groovy TimeCategory/Date: Dates between 2016-03-22 and 2016-03-29 : 6
> Joda Time: Dates between 2016-03-22 and 2016-03-29 : 7
> {noformat}
> Expected Output:
> {noformat}
> $ groovy DatesDiff.groovy
> Java 8 ChronoUnit: Dates between 2016-03-22 and 2016-03-29 : 7
> Groovy TimeCategory/Date: Dates between 2016-03-22 and 2016-03-29 : 7
> Joda Time: Dates between 2016-03-22 and 2016-03-29 : 7
> {noformat}
> Resume: notice the difference in "Groovy TimeCategory/Date" line.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (GROOVY-7964) TimeCategory incorrectly counts days difference between two dates
[
https://issues.apache.org/jira/browse/GROOVY-7964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15573385#comment-15573385
]
Los Pejos edited comment on GROOVY-7964 at 10/13/16 10:20 PM:
--
Well, I run this script, and on the same OS with the same jvm and timezone java
versions (ChronoUnit and JodaTime) has no errors, while Groovy TimeCategory
has. Thus I suppose TimeCategory is buggy. Currently as a workaround I moved
from TimeCategory to ChronoUnit all my projects code.
was (Author: lospejos):
Well, I run this script, and on the same OS with the same jvm and timezone java
versions (ChronoUnit and JodaTime) has no errors, while Groovy TimeCategory
has. Thus I suppose TineCategory is buggy. Currently as a workaround I moved
from TimeCategory to ChronoUnit all my projects code.
> TimeCategory incorrectly counts days difference between two dates
> -
>
> Key: GROOVY-7964
> URL: https://issues.apache.org/jira/browse/GROOVY-7964
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.4.7
> Environment: Windows 10 x86_64, Oracle Java 1.8.0.102 x86_64
>Reporter: Los Pejos
> Labels: timecategory
> Attachments: DatesDiff.groovy
>
>
> TimeCategory incorrectly counts days difference between two dates.
> Exhibit (Groovy code):
> {code}
> #!/usr/bin/env groovy
> @Grab(group='joda-time', module='joda-time', version='2.9.4+')
> import java.io.BufferedReader
> import java.io.IOException
> import java.io.InputStreamReader
> import java.time.LocalDate
> import java.time.format.DateTimeFormatter
> import java.time.temporal.ChronoUnit
> import groovy.time.TimeCategory
> String date1 = '2016-03-22'
> String date2 = '2016-03-29'
> String fmt = '-MM-dd'
> // Java 8 ChronoUnit:
> DateTimeFormatter formatter = DateTimeFormatter.ofPattern(fmt)
> //LocalDate firstDate = LocalDate.parse(date1, formatter)
> //LocalDate secondDate = LocalDate.parse(date2, formatter)
> long days = ChronoUnit.DAYS.between(
> LocalDate.parse(date1, formatter),
> LocalDate.parse(date2, formatter)
> )
> println "Java 8 ChronoUnit: Dates between $date1 and $date2 : $days"
> // Groovy TimeCategory/Date:
> use (TimeCategory) {
> def d = (Date.parse(fmt, date2) - Date.parse(fmt, date1)).days
> println "Groovy TimeCategory/Date: Dates between $date1 and $date2 : $d"
> }
> // Joda Time:
> // LocalDate fromDateFields(Date date)
> // Date.parse('-MM-dd', dlf.@dldpf.toString())
> days = org.joda.time.Days.daysBetween(
> org.joda.time.LocalDate.fromDateFields(Date.parse(fmt,date1)),
> org.joda.time.LocalDate.fromDateFields(Date.parse(fmt,date2))
> ).getDays()
> println "Joda Time: Dates between $date1 and $date2 : $days"
> {code}
> Current Output:
> {noformat}
> $ groovy DatesDiff.groovy
> Java 8 ChronoUnit: Dates between 2016-03-22 and 2016-03-29 : 7
> Groovy TimeCategory/Date: Dates between 2016-03-22 and 2016-03-29 : 6
> Joda Time: Dates between 2016-03-22 and 2016-03-29 : 7
> {noformat}
> Expected Output:
> {noformat}
> $ groovy DatesDiff.groovy
> Java 8 ChronoUnit: Dates between 2016-03-22 and 2016-03-29 : 7
> Groovy TimeCategory/Date: Dates between 2016-03-22 and 2016-03-29 : 7
> Joda Time: Dates between 2016-03-22 and 2016-03-29 : 7
> {noformat}
> Resume: notice the difference in "Groovy TimeCategory/Date" line.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7964) TimeCategory incorrectly counts days difference between two dates
[
https://issues.apache.org/jira/browse/GROOVY-7964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15573385#comment-15573385
]
Los Pejos commented on GROOVY-7964:
---
Well, I run this script, and on the same OS with the same jvm and timezone java
versions (ChronoUnit and JodaTime) has no errors, while Groovy TimeCategory
has. Thus I suppose TineCategory is buggy, Currently as a workaround I moved
from TimeCategory to ChronoUnit all my projects code.
> TimeCategory incorrectly counts days difference between two dates
> -
>
> Key: GROOVY-7964
> URL: https://issues.apache.org/jira/browse/GROOVY-7964
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.4.7
> Environment: Windows 10 x86_64, Oracle Java 1.8.0.102 x86_64
>Reporter: Los Pejos
> Labels: timecategory
> Attachments: DatesDiff.groovy
>
>
> TimeCategory incorrectly counts days difference between two dates.
> Exhibit (Groovy code):
> {code}
> #!/usr/bin/env groovy
> @Grab(group='joda-time', module='joda-time', version='2.9.4+')
> import java.io.BufferedReader
> import java.io.IOException
> import java.io.InputStreamReader
> import java.time.LocalDate
> import java.time.format.DateTimeFormatter
> import java.time.temporal.ChronoUnit
> import groovy.time.TimeCategory
> String date1 = '2016-03-22'
> String date2 = '2016-03-29'
> String fmt = '-MM-dd'
> // Java 8 ChronoUnit:
> DateTimeFormatter formatter = DateTimeFormatter.ofPattern(fmt)
> //LocalDate firstDate = LocalDate.parse(date1, formatter)
> //LocalDate secondDate = LocalDate.parse(date2, formatter)
> long days = ChronoUnit.DAYS.between(
> LocalDate.parse(date1, formatter),
> LocalDate.parse(date2, formatter)
> )
> println "Java 8 ChronoUnit: Dates between $date1 and $date2 : $days"
> // Groovy TimeCategory/Date:
> use (TimeCategory) {
> def d = (Date.parse(fmt, date2) - Date.parse(fmt, date1)).days
> println "Groovy TimeCategory/Date: Dates between $date1 and $date2 : $d"
> }
> // Joda Time:
> // LocalDate fromDateFields(Date date)
> // Date.parse('-MM-dd', dlf.@dldpf.toString())
> days = org.joda.time.Days.daysBetween(
> org.joda.time.LocalDate.fromDateFields(Date.parse(fmt,date1)),
> org.joda.time.LocalDate.fromDateFields(Date.parse(fmt,date2))
> ).getDays()
> println "Joda Time: Dates between $date1 and $date2 : $days"
> {code}
> Current Output:
> {noformat}
> $ groovy DatesDiff.groovy
> Java 8 ChronoUnit: Dates between 2016-03-22 and 2016-03-29 : 7
> Groovy TimeCategory/Date: Dates between 2016-03-22 and 2016-03-29 : 6
> Joda Time: Dates between 2016-03-22 and 2016-03-29 : 7
> {noformat}
> Expected Output:
> {noformat}
> $ groovy DatesDiff.groovy
> Java 8 ChronoUnit: Dates between 2016-03-22 and 2016-03-29 : 7
> Groovy TimeCategory/Date: Dates between 2016-03-22 and 2016-03-29 : 7
> Joda Time: Dates between 2016-03-22 and 2016-03-29 : 7
> {noformat}
> Resume: notice the difference in "Groovy TimeCategory/Date" line.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (GROOVY-7967) AstNodeToScriptAdapter should output source using the recommended modifier order
[
https://issues.apache.org/jira/browse/GROOVY-7967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-7967.
---
Resolution: Fixed
Fix Version/s: 2.5.0-beta-1
Proposed PR merged to master (targeting 2.5+)
> AstNodeToScriptAdapter should output source using the recommended modifier
> order
>
>
> Key: GROOVY-7967
> URL: https://issues.apache.org/jira/browse/GROOVY-7967
> Project: Groovy
> Issue Type: Bug
>Reporter: Paul King
>Assignee: Paul King
> Labels: breaking
> Fix For: 2.5.0-beta-1
>
>
> This source file:
> {code}
> interface Foo { }
> {code}
> when 'reprinted' via the groovyConsole shows up as:
> {code}
> abstract interface public class Foo extends java.lang.Object { }
> {code}
> We don't need to have both 'interface' and 'class' and the modifier order
> should follow the JLS recommendations.
> In some sense this is a trviial change but we do have numerous tests which
> output the resulting source and check the value. We'll need to refactor those.
> It is a breaking change only if the old source order was being relied upon.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7969) Incorrect modifers on setter for volatile property with @Bindable/@Vetoable
[
https://issues.apache.org/jira/browse/GROOVY-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15571138#comment-15571138
]
ASF GitHub Bot commented on GROOVY-7969:
Github user paulk-asert closed the pull request at:
https://github.com/apache/groovy/pull/448
> Incorrect modifers on setter for volatile property with @Bindable/@Vetoable
> ---
>
> Key: GROOVY-7969
> URL: https://issues.apache.org/jira/browse/GROOVY-7969
> Project: Groovy
> Issue Type: Bug
>Reporter: Paul King
>Assignee: Paul King
> Fix For: 2.4.8
>
>
> As part of GROOVY-3726 we fixed getter/setter method modifiers for volatile
> (or transient) properties. The @Bindable and @Vetoable transforms however
> generate their own setters and bypass that fix.
> Here is a script to reproduce the problem:
> {code}
> import static java.lang.reflect.Modifier.toString
> import groovy.beans.Bindable
> class Foo {
> volatile Date now
> }
> @Bindable class Bar {
> volatile Date then
> }
> void pretty(int mod) { println "${mod.toString().padRight(10)}" +
> toString(mod) }
> pretty(Foo.getMethod('getNow').modifiers)
> pretty(Foo.getMethod('setNow', Date).modifiers)
> pretty(Bar.getMethod('getThen').modifiers)
> pretty(Bar.getMethod('setThen', Date).modifiers)
> {code}
> which currently produces:
> {noformat}
> 1 public
> 1 public
> 1 public
> 65public volatile
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] groovy pull request #448: GROOVY-7969: Incorrect modifers on setter for vola...
Github user paulk-asert closed the pull request at: https://github.com/apache/groovy/pull/448 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Resolved] (GROOVY-7969) Incorrect modifers on setter for volatile property with @Bindable/@Vetoable
[
https://issues.apache.org/jira/browse/GROOVY-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-7969.
---
Resolution: Fixed
Assignee: Paul King
Fix Version/s: 2.4.8
Proposed PR merged with Jochen's suggestions
> Incorrect modifers on setter for volatile property with @Bindable/@Vetoable
> ---
>
> Key: GROOVY-7969
> URL: https://issues.apache.org/jira/browse/GROOVY-7969
> Project: Groovy
> Issue Type: Bug
>Reporter: Paul King
>Assignee: Paul King
> Fix For: 2.4.8
>
>
> As part of GROOVY-3726 we fixed getter/setter method modifiers for volatile
> (or transient) properties. The @Bindable and @Vetoable transforms however
> generate their own setters and bypass that fix.
> Here is a script to reproduce the problem:
> {code}
> import static java.lang.reflect.Modifier.toString
> import groovy.beans.Bindable
> class Foo {
> volatile Date now
> }
> @Bindable class Bar {
> volatile Date then
> }
> void pretty(int mod) { println "${mod.toString().padRight(10)}" +
> toString(mod) }
> pretty(Foo.getMethod('getNow').modifiers)
> pretty(Foo.getMethod('setNow', Date).modifiers)
> pretty(Bar.getMethod('getThen').modifiers)
> pretty(Bar.getMethod('setThen', Date).modifiers)
> {code}
> which currently produces:
> {noformat}
> 1 public
> 1 public
> 1 public
> 65public volatile
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7948) tab completion for static imports in groovysh does not work
[
https://issues.apache.org/jira/browse/GROOVY-7948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15571108#comment-15571108
]
ASF GitHub Bot commented on GROOVY-7948:
Github user blackdrag commented on a diff in the pull request:
https://github.com/apache/groovy/pull/438#discussion_r83155709
--- Diff:
subprojects/groovy-groovysh/src/main/groovy/org/codehaus/groovy/tools/shell/completion/ImportsSyntaxCompletor.groovy
---
@@ -87,51 +78,49 @@ class ImportsSyntaxCompletor implements
IdentifierCompletor {
return foundMatch
}
-private static final String STATIC_IMPORT_PATTERN = ~/^import static
([a-z0-9]+\.)+[A-Z][a-zA-Z0-9]*(\.(\*|[^.]+))?$/
+private static final String STATIC_IMPORT_PATTERN = ~/^static
([a-zA-Z_][a-zA-Z_0-9]*\.)+([a-zA-Z_][a-zA-Z_0-9]*|\*)$/
/**
* finds matching imported classes or static methods
- * @param prefix
- * @param importSpec
- * @param matches
- * @return
+ * @param importSpec an import statement without the leading 'import '
or trailing semicolon
+ * @return all names matching the importSpec
*/
-void collectImportedSymbols(final String importSpec, final
Collection matches) {
+SortedSet collectImportedSymbols(final String importSpec) {
--- End diff --
we decided to be strict about such things in a bugfix release and 2.4.8 is
one. So yeah, unless the method signature is made compatible no 2.4.x
> tab completion for static imports in groovysh does not work
> ---
>
> Key: GROOVY-7948
> URL: https://issues.apache.org/jira/browse/GROOVY-7948
> Project: Groovy
> Issue Type: Bug
> Components: Groovysh
>Affects Versions: 2.4.7
>Reporter: Abraham Grief
>
> Currently, if I run groovysh, and enter the following:
> {noformat}
> class MyMath {
> static int square(int x) {return x*x}
> }
> import static MyMath.*
> {noformat}
> Then enter {noformat}sq{noformat} followed by hitting the Tab key, groovysh
> does not provided any possible auto-completions.
> Instead, hitting the Tab key should auto-complete to the square method in
> MyMath.
> I fixed this already in my local groovy installation and can submit it as a
> pull request if that helps.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] groovy pull request #438: GROOVY-7948: fix completion of static imports in g...
Github user blackdrag commented on a diff in the pull request:
https://github.com/apache/groovy/pull/438#discussion_r83155709
--- Diff:
subprojects/groovy-groovysh/src/main/groovy/org/codehaus/groovy/tools/shell/completion/ImportsSyntaxCompletor.groovy
---
@@ -87,51 +78,49 @@ class ImportsSyntaxCompletor implements
IdentifierCompletor {
return foundMatch
}
-private static final String STATIC_IMPORT_PATTERN = ~/^import static
([a-z0-9]+\.)+[A-Z][a-zA-Z0-9]*(\.(\*|[^.]+))?$/
+private static final String STATIC_IMPORT_PATTERN = ~/^static
([a-zA-Z_][a-zA-Z_0-9]*\.)+([a-zA-Z_][a-zA-Z_0-9]*|\*)$/
/**
* finds matching imported classes or static methods
- * @param prefix
- * @param importSpec
- * @param matches
- * @return
+ * @param importSpec an import statement without the leading 'import '
or trailing semicolon
+ * @return all names matching the importSpec
*/
-void collectImportedSymbols(final String importSpec, final
Collection matches) {
+SortedSet collectImportedSymbols(final String importSpec) {
--- End diff --
we decided to be strict about such things in a bugfix release and 2.4.8 is
one. So yeah, unless the method signature is made compatible no 2.4.x
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
