You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@groovy.apache.org by Joe Wolf <jo...@gmail.com> on 2017/05/06 20:30:04 UTC
Java 8 Date/Time API Extension Methods
Hi, I want to announce the 1.0 release of an OSS project I've been working
on called goodtimes.
The Groovy JDK has always been one of my favorite parts of Groovy, but it
currently lacks support for newer Java 8 classes. Goodtimes fills some of
this gap until the GDK is updated by providing extension methods for the
Java 8 Date/Time API akin to those available for java.util.Date and
Calendar.
Source and documentation are hosted on GitHub: https://github.com/bdkosher/
goodtimes
Just add the dependency to your classpath to give it a try (assuming you're
on Java 8, of course).
@Grab('com.github.bdkosher:goodtimes:1.0')
compile 'com.github.bdkosher:goodtimes:1.0'
-Joe
@bdkosher
Re: Java 8 Date/Time API Extension Methods
Posted by Daniel Sun <re...@hotmail.com>.
Hi Joe,
Thanks for your awesome work. I like it.
Cheers,
Daniel.Sun
--
View this message in context: http://groovy.329449.n5.nabble.com/Java-8-Date-Time-API-Extension-Methods-tp5740663p5741533.html
Sent from the Groovy Users mailing list archive at Nabble.com.
Re: Java 8 Date/Time API Extension Methods
Posted by jim northrop <ja...@googlemail.com>.
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 <jo...@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 <gl...@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 <jo...@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 <ma...@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 <pa...@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č <di...@gmail.com> wrote:
>>>>>> On 8 June 2017 at 13:34, Russel Winder <ru...@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 <ru...@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
>>
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge / Google+
>
Re: Java 8 Date/Time API Extension Methods
Posted by Guillaume Laforge <gl...@gmail.com>.
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 <jo...@gmail.com> 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 <gl...@gmail.com>
> 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 <al...@gmail.com>
>> 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 <jo...@gmail.com> 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 <gl...@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 <jo...@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 <ma...@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 <pa...@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 <ru...@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 <ru...@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
>>>>>
>>>>> Blog: http://glaforge.appspot.com/
>>>>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>>>>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>>>>
>>>>
>>>>
>>
>>
>> --
>> Guillaume Laforge
>> Apache Groovy committer & PMC Vice-President
>> Developer Advocate @ Google Cloud Platform
>>
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>
>
>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: Java 8 Date/Time API Extension Methods
Posted by Joe Wolf <jo...@gmail.com>.
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 <gl...@gmail.com>
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 <al...@gmail.com>
> 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 <jo...@gmail.com> 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 <gl...@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 <jo...@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 <ma...@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 <pa...@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č <di...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On 8 June 2017 at 13:34, Russel Winder <ru...@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 <ru...@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
>>>>
>>>> Blog: http://glaforge.appspot.com/
>>>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>>>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>>>
>>>
>>>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>
Re: Java 8 Date/Time API Extension Methods
Posted by Guillaume Laforge <gl...@gmail.com>.
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 <al...@gmail.com> 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 <jo...@gmail.com> 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 <gl...@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 <jo...@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 <ma...@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 <pa...@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č <di...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On 8 June 2017 at 13:34, Russel Winder <ru...@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 <ru...@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
>>>
>>> Blog: http://glaforge.appspot.com/
>>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>>
>>
>>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: Java 8 Date/Time API Extension Methods
Posted by jim northrop <ja...@googlemail.com>.
Right Ahm,
Good point. Backward compatibility helps not only us old-time groovy ppl but also the new generation of converts to Groovy 👍✅
Sent from my iPad
> On 26 Jun 2017, at 08:10, Ahm Avoby <al...@gmail.com> 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 <jo...@gmail.com> 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 <gl...@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 <jo...@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 <ma...@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 <pa...@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č <di...@gmail.com> wrote:
>>>>>>> On 8 June 2017 at 13:34, Russel Winder <ru...@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 <ru...@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
>>>
>>> Blog: http://glaforge.appspot.com/
>>> Social: @glaforge / Google+
>>
Re: Java 8 Date/Time API Extension Methods
Posted by Ahm Avoby <al...@gmail.com>.
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 <jo...@gmail.com> 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 <gl...@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 <jo...@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 <ma...@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 <pa...@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č <di...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On 8 June 2017 at 13:34, Russel Winder <ru...@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 <ru...@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
>>
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>
>
>
Re: Java 8 Date/Time API Extension Methods
Posted by Joe Wolf <jo...@gmail.com>.
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 <gl...@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 <jo...@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 <ma...@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 <pa...@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č <di...@gmail.com>
>>>> wrote:
>>>>
>>>>> On 8 June 2017 at 13:34, Russel Winder <ru...@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 <ru...@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
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>
Re: Java 8 Date/Time API Extension Methods
Posted by Guillaume Laforge <gl...@gmail.com>.
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 <jo...@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 <ma...@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 <pa...@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č <di...@gmail.com>
>>> wrote:
>>>
>>>> On 8 June 2017 at 13:34, Russel Winder <ru...@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 <ru...@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
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: Java 8 Date/Time API Extension Methods
Posted by Wilson MacGyver <wm...@gmail.com>.
hibernate 5 supports java.time via hibernate-java8.jar
more info at https://www.thoughts-on-java.org/hibernate-5-date-and-time/
JPA doesn't yet till 2.2
On Thu, Jun 8, 2017 at 11:21 PM, Tankerbay <ta...@gmail.com> wrote:
> Is there still a legacy issue in that many ORMs (including the version of
> Grails I'm using) tend to use java.sql.Date which has the benefit of
> extending java.util.Date?
>
> Is there Hibernate support for java.time yet?
>
> On Thu, Jun 8, 2017 at 8:07 PM, Joe Wolf <jo...@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 <ma...@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 <pa...@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č <di...@gmail.com>
>>>> wrote:
>>>>
>>>>> On 8 June 2017 at 13:34, Russel Winder <ru...@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 <ru...@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
>>>>>
>>>>
>>>>
>>>
>>
>
--
Omnem crede diem tibi diluxisse supremum.
Re: Java 8 Date/Time API Extension Methods
Posted by James Kleeh <ja...@gmail.com>.
Grails supports the java 8 date classes with a grails-java8 plugin http://plugins.grails.org/plugin/grails/grails-java8 <http://plugins.grails.org/plugin/grails/grails-java8>
> On Jun 8, 2017, at 11:21 PM, Tankerbay <ta...@gmail.com> wrote:
>
> Is there still a legacy issue in that many ORMs (including the version of Grails I'm using) tend to use java.sql.Date which has the benefit of extending java.util.Date?
>
> Is there Hibernate support for java.time yet?
>
> On Thu, Jun 8, 2017 at 8:07 PM, Joe Wolf <joewolf@gmail.com <ma...@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 <ma...@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 <ma...@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 <ma...@gmail.com>> wrote:
> On 8 June 2017 at 13:34, Russel Winder <russel@winder.org.uk <ma...@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 <ma...@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 <tel:%2B44%2020%207585%202200> voip: sip:russel.winder@ekiga.net <ma...@ekiga.net>
> > 41 Buckmaster Road m: +44 7770 465 077 <tel:%2B44%207770%20465%20077> xmpp: russel@winder.org.uk <ma...@winder.org.uk>
> > London SW11 1EN, UK w: www.russel.org.uk <http://www.russel.org.uk/> skype: russel_winder
>
>
>
>
Re: Java 8 Date/Time API Extension Methods
Posted by Tankerbay <ta...@gmail.com>.
Is there still a legacy issue in that many ORMs (including the version of
Grails I'm using) tend to use java.sql.Date which has the benefit of
extending java.util.Date?
Is there Hibernate support for java.time yet?
On Thu, Jun 8, 2017 at 8:07 PM, Joe Wolf <jo...@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 <ma...@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 <pa...@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č <di...@gmail.com>
>>> wrote:
>>>
>>>> On 8 June 2017 at 13:34, Russel Winder <ru...@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 <ru...@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
>>>>
>>>
>>>
>>
>
Re: Java 8 Date/Time API Extension Methods
Posted by Joe Wolf <jo...@gmail.com>.
+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 <ma...@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 <pa...@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č <di...@gmail.com>
>> wrote:
>>
>>> On 8 June 2017 at 13:34, Russel Winder <ru...@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 <ru...@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
>>>
>>
>>
>
Re: Java 8 Date/Time API Extension Methods
Posted by Mario Garcia <ma...@gmail.com>.
+1
I think Many Groovy applications could benefit from having this in Groovy.
2017-06-09 1:02 GMT+02:00 Paul King <pa...@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č <di...@gmail.com>
> wrote:
>
>> On 8 June 2017 at 13:34, Russel Winder <ru...@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 <ru...@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
>>
>
>
Re: Java 8 Date/Time API Extension Methods
Posted by Paul King <pa...@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č <di...@gmail.com> wrote:
> On 8 June 2017 at 13:34, Russel Winder <ru...@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 <ru...@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
>
Re: Java 8 Date/Time API Extension Methods
Posted by Dinko Srkoč <di...@gmail.com>.
On 8 June 2017 at 13:34, Russel Winder <ru...@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 <ru...@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
Re: Java 8 Date/Time API Extension Methods
Posted by Russel Winder <ru...@winder.org.uk>.
On Thu, 2017-06-08 at 13:18 +0200, Dinko Srkoč wrote:
> On 8 June 2017 at 13:09, Russel Winder <ru...@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.
(*) 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
Re: Java 8 Date/Time API Extension Methods
Posted by Dinko Srkoč <di...@gmail.com>.
On 8 June 2017 at 13:09, Russel Winder <ru...@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" :-)
Cheers,
Dinko
>
> --
> 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
Re: Java 8 Date/Time API Extension Methods
Posted by Russel Winder <ru...@winder.org.uk>.
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?
--
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
Re: Java 8 Date/Time API Extension Methods
Posted by Søren Berg Glasius <so...@glasius.dk>.
I think it makes perfect sense that you can do the same calculations with
java.time.* as you can with java.util.Date
/Søren
On Wed, 7 Jun 2017 at 16:08 Guillaume Laforge <gl...@gmail.com> wrote:
> I'm coming back on this idea of having it directly integrated in Groovy
> core.
>
> Any more thoughts on this from anyone?
>
> On Tue, May 9, 2017 at 3:32 AM, Joe Wolf <jo...@gmail.com> wrote:
>
>> Thanks Søren and Guillaume. I'm glad to finally contribute something to
>> the Groovy community!
>>
>> On Sun, May 7, 2017 at 4:14 PM, Guillaume Laforge <gl...@gmail.com>
>> wrote:
>>
>>> This is indeed cool, and I'm wondering if it shouldn't be part of Groovy
>>> itself directly :-)
>>>
>>> On Sun, May 7, 2017 at 10:09 PM, Søren Berg Glasius <so...@glasius.dk>
>>> wrote:
>>>
>>>> Well done! Thank you for sharing!
>>>>
>>>> /Søren
>>>>
>>>>
>>>> On Sat, 6 May 2017 at 22:30 Joe Wolf <jo...@gmail.com> wrote:
>>>>
>>>>> Hi, I want to announce the 1.0 release of an OSS project I've been
>>>>> working on called goodtimes.
>>>>>
>>>>> The Groovy JDK has always been one of my favorite parts of Groovy, but
>>>>> it currently lacks support for newer Java 8 classes. Goodtimes fills some
>>>>> of this gap until the GDK is updated by providing extension methods for the
>>>>> Java 8 Date/Time API akin to those available for java.util.Date and
>>>>> Calendar.
>>>>>
>>>>> Source and documentation are hosted on GitHub:
>>>>> https://github.com/bdkosher/goodtimes
>>>>>
>>>>> Just add the dependency to your classpath to give it a try (assuming
>>>>> you're on Java 8, of course).
>>>>>
>>>>> @Grab('com.github.bdkosher:goodtimes:1.0')
>>>>>
>>>>> compile 'com.github.bdkosher:goodtimes:1.0'
>>>>>
>>>>> -Joe
>>>>> @bdkosher
>>>>>
>>>> --
>>>> Best regards / Med venlig hilsen,
>>>> Søren Berg Glasius
>>>>
>>>> Hedevej 1, Gl. Rye, 8680 Ry, Denmark
>>>> Mobile: +45 40 44 91 88 <+45%2040%2044%2091%2088>, Skype: sbglasius
>>>> --- Press ESC once to quit - twice to save the changes.
>>>>
>>>
>>>
>>>
>>> --
>>> Guillaume Laforge
>>> Apache Groovy committer & PMC Vice-President
>>> Developer Advocate @ Google Cloud Platform
>>>
>>> Blog: http://glaforge.appspot.com/
>>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>>
>>
>>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>
--
Best regards / Med venlig hilsen,
Søren Berg Glasius
Hedevej 1, Gl. Rye, 8680 Ry, Denmark
Mobile: +45 40 44 91 88, Skype: sbglasius
--- Press ESC once to quit - twice to save the changes.
Re: Java 8 Date/Time API Extension Methods
Posted by Guillaume Laforge <gl...@gmail.com>.
I'm coming back on this idea of having it directly integrated in Groovy
core.
Any more thoughts on this from anyone?
On Tue, May 9, 2017 at 3:32 AM, Joe Wolf <jo...@gmail.com> wrote:
> Thanks Søren and Guillaume. I'm glad to finally contribute something to
> the Groovy community!
>
> On Sun, May 7, 2017 at 4:14 PM, Guillaume Laforge <gl...@gmail.com>
> wrote:
>
>> This is indeed cool, and I'm wondering if it shouldn't be part of Groovy
>> itself directly :-)
>>
>> On Sun, May 7, 2017 at 10:09 PM, Søren Berg Glasius <so...@glasius.dk>
>> wrote:
>>
>>> Well done! Thank you for sharing!
>>>
>>> /Søren
>>>
>>>
>>> On Sat, 6 May 2017 at 22:30 Joe Wolf <jo...@gmail.com> wrote:
>>>
>>>> Hi, I want to announce the 1.0 release of an OSS project I've been
>>>> working on called goodtimes.
>>>>
>>>> The Groovy JDK has always been one of my favorite parts of Groovy, but
>>>> it currently lacks support for newer Java 8 classes. Goodtimes fills some
>>>> of this gap until the GDK is updated by providing extension methods for the
>>>> Java 8 Date/Time API akin to those available for java.util.Date and
>>>> Calendar.
>>>>
>>>> Source and documentation are hosted on GitHub: https://github.com/bdk
>>>> osher/goodtimes
>>>>
>>>> Just add the dependency to your classpath to give it a try (assuming
>>>> you're on Java 8, of course).
>>>>
>>>> @Grab('com.github.bdkosher:goodtimes:1.0')
>>>>
>>>> compile 'com.github.bdkosher:goodtimes:1.0'
>>>>
>>>> -Joe
>>>> @bdkosher
>>>>
>>> --
>>> Best regards / Med venlig hilsen,
>>> Søren Berg Glasius
>>>
>>> Hedevej 1, Gl. Rye, 8680 Ry, Denmark
>>> Mobile: +45 40 44 91 88 <+45%2040%2044%2091%2088>, Skype: sbglasius
>>> --- Press ESC once to quit - twice to save the changes.
>>>
>>
>>
>>
>> --
>> Guillaume Laforge
>> Apache Groovy committer & PMC Vice-President
>> Developer Advocate @ Google Cloud Platform
>>
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>
>
>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: Java 8 Date/Time API Extension Methods
Posted by Joe Wolf <jo...@gmail.com>.
Thanks Søren and Guillaume. I'm glad to finally contribute something to the
Groovy community!
On Sun, May 7, 2017 at 4:14 PM, Guillaume Laforge <gl...@gmail.com>
wrote:
> This is indeed cool, and I'm wondering if it shouldn't be part of Groovy
> itself directly :-)
>
> On Sun, May 7, 2017 at 10:09 PM, Søren Berg Glasius <so...@glasius.dk>
> wrote:
>
>> Well done! Thank you for sharing!
>>
>> /Søren
>>
>>
>> On Sat, 6 May 2017 at 22:30 Joe Wolf <jo...@gmail.com> wrote:
>>
>>> Hi, I want to announce the 1.0 release of an OSS project I've been
>>> working on called goodtimes.
>>>
>>> The Groovy JDK has always been one of my favorite parts of Groovy, but
>>> it currently lacks support for newer Java 8 classes. Goodtimes fills some
>>> of this gap until the GDK is updated by providing extension methods for the
>>> Java 8 Date/Time API akin to those available for java.util.Date and
>>> Calendar.
>>>
>>> Source and documentation are hosted on GitHub: https://github.com/bdk
>>> osher/goodtimes
>>>
>>> Just add the dependency to your classpath to give it a try (assuming
>>> you're on Java 8, of course).
>>>
>>> @Grab('com.github.bdkosher:goodtimes:1.0')
>>>
>>> compile 'com.github.bdkosher:goodtimes:1.0'
>>>
>>> -Joe
>>> @bdkosher
>>>
>> --
>> Best regards / Med venlig hilsen,
>> Søren Berg Glasius
>>
>> Hedevej 1, Gl. Rye, 8680 Ry, Denmark
>> Mobile: +45 40 44 91 88 <+45%2040%2044%2091%2088>, Skype: sbglasius
>> --- Press ESC once to quit - twice to save the changes.
>>
>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>
Re: Java 8 Date/Time API Extension Methods
Posted by Guillaume Laforge <gl...@gmail.com>.
This is indeed cool, and I'm wondering if it shouldn't be part of Groovy
itself directly :-)
On Sun, May 7, 2017 at 10:09 PM, Søren Berg Glasius <so...@glasius.dk>
wrote:
> Well done! Thank you for sharing!
>
> /Søren
>
>
> On Sat, 6 May 2017 at 22:30 Joe Wolf <jo...@gmail.com> wrote:
>
>> Hi, I want to announce the 1.0 release of an OSS project I've been
>> working on called goodtimes.
>>
>> The Groovy JDK has always been one of my favorite parts of Groovy, but it
>> currently lacks support for newer Java 8 classes. Goodtimes fills some of
>> this gap until the GDK is updated by providing extension methods for the
>> Java 8 Date/Time API akin to those available for java.util.Date and
>> Calendar.
>>
>> Source and documentation are hosted on GitHub: https://github.com/
>> bdkosher/goodtimes
>>
>> Just add the dependency to your classpath to give it a try (assuming
>> you're on Java 8, of course).
>>
>> @Grab('com.github.bdkosher:goodtimes:1.0')
>>
>> compile 'com.github.bdkosher:goodtimes:1.0'
>>
>> -Joe
>> @bdkosher
>>
> --
> Best regards / Med venlig hilsen,
> Søren Berg Glasius
>
> Hedevej 1, Gl. Rye, 8680 Ry, Denmark
> Mobile: +45 40 44 91 88 <+45%2040%2044%2091%2088>, Skype: sbglasius
> --- Press ESC once to quit - twice to save the changes.
>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: Java 8 Date/Time API Extension Methods
Posted by Søren Berg Glasius <so...@glasius.dk>.
Well done! Thank you for sharing!
/Søren
On Sat, 6 May 2017 at 22:30 Joe Wolf <jo...@gmail.com> wrote:
> Hi, I want to announce the 1.0 release of an OSS project I've been working
> on called goodtimes.
>
> The Groovy JDK has always been one of my favorite parts of Groovy, but it
> currently lacks support for newer Java 8 classes. Goodtimes fills some of
> this gap until the GDK is updated by providing extension methods for the
> Java 8 Date/Time API akin to those available for java.util.Date and
> Calendar.
>
> Source and documentation are hosted on GitHub:
> https://github.com/bdkosher/goodtimes
>
> Just add the dependency to your classpath to give it a try (assuming
> you're on Java 8, of course).
>
> @Grab('com.github.bdkosher:goodtimes:1.0')
>
> compile 'com.github.bdkosher:goodtimes:1.0'
>
> -Joe
> @bdkosher
>
--
Best regards / Med venlig hilsen,
Søren Berg Glasius
Hedevej 1, Gl. Rye, 8680 Ry, Denmark
Mobile: +45 40 44 91 88, Skype: sbglasius
--- Press ESC once to quit - twice to save the changes.