Lovely piece of work Joe! 👏 Bet you needed a few aspirins to complete this baby. Can we do date arithmetic like 'new Date()+7 days'. or similar? Or maybe thats not part of your code?

Sent from my iPad

On 25 Jun 2017, at 23:31, Joe Wolf <joewolf@gmail.com> wrote:

Goodtimes 1.1 is out with new extension methods on the zone-based types, effectively covering the entire java.time.* package (except for Clock, which I haven't found need to extend). I'd say I'm about 98% content with the API.

I'm mulling the addition of static parse() methods akin to the Groovy JDK's Date.parse(String format, String input) method, but am wrestling with argument ordering. Date.parse accepts the format as the first argument; the new java.time API parse methods accept the date/time string first. Although I've aimed to be consistent with the Groovy JDK thus far, I'm leaning towards following the Java 8 API ordering in this case.

On the other side of the coin, I am contemplating jettisoning the upto and downto methods. Since the java.time types are Comparable and goodtimes adds next() and previous() methods, the range operator can be used to replicate their function

earlier.upto(later) {} --> (earlier..later).each {}
later.downto(earlier) {} --> (later..earlier).each {}

I'm also questioning the existence of the getAt(int calendarField) methods. On the downside, it's munging the older java.util API with the new; on the upside, I don't have to explicitly import java.time.temporal.ChronoField. java.util.Calendar comes for free.

-Joe

On Fri, Jun 9, 2017 at 8:51 AM, Guillaume Laforge <glaforge@gmail.com> wrote:
Keep us updated on the new extensions, and once you're happy with what you have come up with, I believe it'd really be awesome to have it integrated.

Guillaume


On Fri, Jun 9, 2017 at 5:07 AM, Joe Wolf <joewolf@gmail.com> wrote:
+1 for me. I think it's a good idea.

Not everything in the current API may be worthwhile to have as part of Groovy proper, though. For example, the bridging methods from the java.time classes back to Date and Calendar could be unnecessarily promoting the latter's usage.

By the way, I'm currently working to add extension methods to the java.time types involving ZoneId and ZoneOffset. I hope to have that completed in a couple of weeks or so.

-Joe

On Thu, Jun 8, 2017 at 7:52 PM, Mario Garcia <mario.ggar@gmail.com> wrote:
+1 

I think Many Groovy applications could benefit from having this in Groovy.

2017-06-09 1:02 GMT+02:00 Paul King <paulk@asert.com.au>:
+1 from me, but I'd be keen to hear Joe's thoughts?

Cheers, Paul.


On Thu, Jun 8, 2017 at 10:37 PM, Dinko Srkoč <dinko.srkoc@gmail.com> wrote:
On 8 June 2017 at 13:34, Russel Winder <russel@winder.org.uk> wrote:
> On Thu, 2017-06-08 at 13:18 +0200, Dinko Srkoč wrote:
>> On 8 June 2017 at 13:09, Russel Winder <russel@winder.org.uk> wrote:
>> > On Wed, 2017-06-07 at 14:38 +0000, Søren Berg Glasius wrote:
>> > > I think it makes perfect sense that you can do the same
>> > > calculations
>> > > with
>> > > java.time.* as you can with java.util.Date
>> > >
>> >
>> > Shouldn't it be fair to assume that all new code eschews
>> > java.util.Date
>> > and all the Calendar stuff, and uses java.time for everything time
>> > and
>> > date related?
>>
>> I think this falls into a category of "hope" or "wish", rather than
>> "assumption" :-)
>
> True, but I was hoping that unlike a large percentage of Java
> developers who are hugely reluctant to learn anything new they do not
> already know (*), Groovy developers were very much into using the best
> new idiomatic ways of doing things (well except for stuff that is just
> fashionably trendy for a few days) and keeping their codebases up to
> date with up-to-date Groovy.
>
> Please do not shatter my illusions.

haha!

Okay, I could convince myself that it is indeed so with Groovy developers. :-)

>
>
>
> (*) And are thus part of the legacy problem.
>
> --
> Russel.
> =============================================================================
> Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net
> 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder






--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform