groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Wolf <>
Subject Re: Java 8 Date/Time API Extensions Methods [GROOVY-8334]
Date Wed, 21 Mar 2018 17:57:48 GMT
(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 LocalDate parse(CharSequence value, DateTimeFormatter format)

The new extension parse method is a more convenient form of the latter
method, which basically treats the formatter as an optional argument.

The second reason is that the ordering reads better to me; no need for a
comma pause: "parse this String with this pattern" vs. "with this pattern,
parse this String"

The third reason is that it could better support overriding the method in
the future to accept more than one pattern, akin to commons-lang DateUtil's
parseDate method (

(2) In addition to the variation you mentioned (which I think is a good
idea), I was mulling yet another upto variation that takes an additional
argument that defines how to deal with the inclusivity of the end argument.
There are three variations as I see it:
- strict
- unit
- exact

The names definitely need work, but it would work like this: consider
iterating from March 1st until March 2nd using a unit of Months
- "strict" = the current behavior--never let the current value exceed the
end value: e.g. closure is invoked with March 1st and the method returns
- "unit" = the behavior where the iteration stops as the current value is
greater than one unit from the target: e.g. closure is invoked once with
March 1st and once with April 1st before returning
- "exact" = this would mean that the end argument is included in the
iteration whether or not it's "landed on" exactly: e.g. the closure is
invoked once with March 1st and once with March 2nd

But, given the complexity of even having to explain this and come up with
reasonable names for the optional "inclusivity" enum values, I find your
suggestion of stepUp(from, to, unit, amount) appealing.


On Wed, Mar 21, 2018 at 1:17 PM, Paul King <> wrote:

> 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('yyyy-MM-dd', '2000-01-01')
> LocalDate jan02 = LocalDate.parse('2000-01-02', 'yyyy-MM-dd')
> Okay if I swap the order of arguments around for consistency with the
> existing Date methods?
> (2) I was pondering upto variations. Groovy has a step method in addition
> to upto which is used when iterating in multiples. It lets you specify an
> increment amount but not a unit, so is not an exact match. It seems like
> having a method that had an increment amount might be useful, e.g. stepping
> between two dates in fortnightly intervals. I guess there are numerous ways
> we could implement such functionality. My current thinking is rename the
> current 3-arg upto method to step but add a fourth amount argument. The
> 3-arg downto could be removed. The step method counts up or down depending
> on whether from or to is biggest. It throws an "infinite loop" runtime
> exception given a zero amount. We could follow that behavior.
> Thoughts?
> Cheers, Paul.
> On Tue, Mar 20, 2018 at 12:48 PM, Paul King <> wrote:
>> 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 compared to other classes but I can see the need for the
>> proposed functionality.
>> I was thinking that we might need to make the same kind of distinction
>> that we do for Range, e.g. inclusive vs exclusive or that Java does in the
>> Streams api, open/closed. But I'll play a little more and propose something
>> more concrete.
>>> On Mon, Mar 19, 2018 at 12:07 PM, Guillaume Laforge <>
>>> wrote:
>>>> Cool!
>>>> On Mon, Mar 19, 2018 at 5:06 PM, Daniel.Sun <> wrote:
>>>>> Merged.
>>>>> Cheers,
>>>>> Daniel.Sun
>>>>> --
>>>>> Sent from:
>>>> --
>>>> Guillaume Laforge
>>>> Apache Groovy committer & PMC Vice-President
>>>> Developer Advocate @ Google Cloud Platform
>>>> Blog:
>>>> Social: @glaforge <> / Google+
>>>> <>

View raw message