I haven't had time to look at step variants yet but I'll leave the parse
methods as is but add in some doco to warn people to expect differences to
the legacy parse methods.
On Thu, Mar 22, 2018 at 3:57 AM, Joe Wolf wrote:
> (1) The parse method argument ordering was a tough call for me, but thr
Datum: 21.03.18 18:57 (GMT+01:00) An: dev@groovy.apache.org, Paul King
Betreff: Re: Java 8 Date/Time API Extensions Methods
[GROOVY-8334]
(1) The parse method argument ordering was a tough call for me, but three
reasons led me to favor the current ordering.
The primary reason was to be con
(1) The parse method argument ordering was a tough call for me, but three
reasons led me to favor the current ordering.
The primary reason was to be consistent with the new Date/Time API itself.
Most types have two static parse methods, e.g.
static LocalDate parse(CharSequence value)
static Local
Okay, I had a bit more of a look at the methods. I think the upto behavior
is fine - though see my comment below. I have two overall comments:
(1) Parse method argument order are reversed to existing methods, e.g.:
Date jan01 = Date.parse('-MM-dd', '2000-01-01')
LocalDate jan02 = LocalDate.pa
On Tue, Mar 20, 2018 at 2:19 AM, Joe Wolf wrote:
> [...] Glad there was consensus on the strict upper bound view for
> upto/downto. [...]
>
Being at the conference the last week, I didn't get time to look at that
properly. It worries me that we'd have a different semantics for
upto/downto compar
Hi Joe,
> Daniel, in regards to being considered as a champion candidate, that's
> flattering, but being able to contribute to Groovy core is honor enough.
You deserve it :-)
> I've benefited from Groovy for years and I've long wanted to give back to
> the community.
So do I.
Cheers,
Daniel
Thanks for the feedback and the pull! Glad there was consensus on the
strict upper bound view for upto/downto. Everything was essentially
straightforward one liners except for those two methods.
Daniel, in regards to being considered as a champion candidate, that's
flattering, but being able to co
Cool!
On Mon, Mar 19, 2018 at 5:06 PM, Daniel.Sun wrote:
> Merged.
> https://github.com/apache/groovy/pull/674
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Devel
Merged.
https://github.com/apache/groovy/pull/674
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
+1!
I've just read the documentation and it's clear and elegant. Great job!
Really looking forward to seeing it integrated!
It's a very nice and needed addition to the GDK :-)
Guillaume
On Sun, Mar 18, 2018 at 6:03 AM, Paul King wrote:
> Looks good at first glance. Please go ahead with the PR
In general I agree that the half-open interval [TS_FROM, TS_TO) should
be the default behavior for intervals due to the reasons given -
whatever detailed influence that has on discrete iterations /
upto/downto :-)
Cheers,
mg
On 18.03.2018 17:45, Alexander Veit wrote:
Hi,
2) changing the be
Hi,
> 2) changing the behavior of the upto method (and downto) so that, when
> using a custom unit of iteration that prevents the start value from being
> incremented exactly to the end value, the method returns as soon as the
> current value becomes strictly later than the end value. In my first
Nice!
I see a Groovy Champion candidate here ;-)
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Looks good at first glance. Please go ahead with the PR.
On 18 Mar. 2018 5:37 am, "Joe Wolf" wrote:
> Here's a first stab at the documentation for the Date/Time API extensions:
> http://bdkosher.github.io/groovy-3.0-alpha/html5/#_working_with_date_
> time_types
>
> And in writing the documentati
Here's a first stab at the documentation for the Date/Time API extensions:
http://bdkosher.github.io/groovy-3.0-alpha/html5/#_working_with_date_time_types
And in writing the documentation (as with writing unit tests), I got
feedback, prompting some minor changes:
1) using the DateTimeFormatter.I
Sounds awesome!
Anyhow, I already like what I see, those methods sound very useful to me!
On Mon, Feb 19, 2018 at 4:37 PM, Joe Wolf wrote:
> Good idea--I should have thought of that earlier! I'll draft up some
> documentation in a new section of the core-gdk.adoc file and post a link
> for revie
Good idea--I should have thought of that earlier! I'll draft up some
documentation in a new section of the core-gdk.adoc file and post a link
for review.
-Joe
On Mon, Feb 19, 2018 at 4:50 AM, Guillaume Laforge
wrote:
> This looks very complete, at first sight, that's really wonderful!
> I'm rea
This looks very complete, at first sight, that's really wonderful!
I'm really looking forward to seeing that integrated.
Did you also have a pointer to a doc / page / blog which shows those
methods in action?
(which we could potentially add to our online documentation)
Guillaume
On Mon, Feb 19,
18 matches
Mail list logo
