Sure, when you're ready / happy, feel free to start a thread on the dev list. On Tue, Jun 27, 2017 at 4:48 AM, Joe Wolf wrote: > I'm all on board for integrating into Groovy, and I'm letting that drive > design decisions as I finish up the changes. I appreciate the feedback on > the API--I will definitely take it all under consideration. Perhaps we > should move integration-related discussions over to the dev mailing list. > > -Joe > > On Mon, Jun 26, 2017 at 7:51 AM, Guillaume Laforge > wrote: > >> I also think it's sane to keep the Java 8 ordering in this case. >> >> Even if we can use ranges, keeping upto / downto in addition would be >> kind to people used to using them. >> >> Anyhow, very nice work! >> I still believe we need to integrate it to Groovy core :-) >> >> Guillaume >> >> On Mon, Jun 26, 2017 at 8:10 AM, Ahm Avoby >> wrote: >> >>> Hi Jim, >>> >>> @static parse(): I am with you on keeping the Java 8 API ordering, but I >>> would not jettison the upto and downto methods, as to not confuse people >>> switching from Java 8 to Groovy. >>> >>> Cheers, >>> Ahm >>> >>> >>> >>> Joe Wolf schrieb am So., 25. Juni 2017, 23:32: >>> >>>> 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 >>>> 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 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 >>>>>> wrote: >>>>>> >>>>>>> +1 >>>>>>> >>>>>>> I think Many Groovy applications could benefit from having this in >>>>>>> Groovy. >>>>>>> >>>>>>> 2017-06-09 1:02 GMT+02:00 Paul King : >>>>>>> >>>>>>>> +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č >>>>>>> > wrote: >>>>>>>> >>>>>>>>> On 8 June 2017 at 13:34, Russel Winder >>>>>>>>> wrote: >>>>>>>>> > On Thu, 2017-06-08 at 13:18 +0200, Dinko Srkoč wrote: >>>>>>>>> >> On 8 June 2017 at 13:09, Russel Winder >>>>>>>>> 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 >>>>> >>>>> Blog: http://glaforge.appspot.com/ >>>>> Social: @glaforge / Google+ >>>>> >>>>> >>>> >>>> >> >> >> -- >> Guillaume Laforge >> Apache Groovy committer & PMC Vice-President >> Developer Advocate @ Google Cloud Platform >> >> Blog: http://glaforge.appspot.com/ >> Social: @glaforge / Google+ >> >> > > -- Guillaume Laforge Apache Groovy committer & PMC Vice-President Developer Advocate @ Google Cloud Platform Blog: http://glaforge.appspot.com/ Social: @glaforge / Google+