Re: Java 8 Date/Time API Extension Methods

[James Kleeh]

Grails supports the java 8 date classes with a grails-java8 plugin 
http://plugins.grails.org/plugin/grails/grails-java8 

> On Jun 8, 2017, at 11:21 PM, Tankerbay  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  > 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 +, 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.win...@ekiga.net 
> > 41 Buckmaster Roadm: +44 7770 465 077    
> > xmpp: rus...@winder.org.uk 
> > London SW11 1EN, UK   w: www.russel.org.uk   
> > skype: russel_winder
> 
> 
> 
> 

Re: Java 8 Date/Time API Extension Methods

[Wilson MacGyver]

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  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  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 +, 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.win...@ekiga.net
> > 41 Buckmaster Roadm: +44 7770 465 077   xmpp:
> rus...@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

[Tankerbay]

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  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 +, 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.win...@ekiga.net
 > 41 Buckmaster Roadm: +44 7770 465 077   xmpp:
 rus...@winder.org.uk
 > London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

>>>
>>>
>>
>

Re: Java 8 Date/Time API Extension Methods

[Joe Wolf]

+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 +, 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.win...@ekiga.net
>>> > 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
>>> > London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>>>
>>
>>
>

Re: Groovy 2.5.0-beta-1 released

[Paul King]

And it's there now:

http://groovy-lang.org/releasenotes/groovy-2.5.html

We might make a nicer fleshed out version for some of those points before
the final release - but at least it's there now.

Cheers, Paul.

On Fri, Jun 9, 2017 at 10:29 AM, Paul King  wrote:

>
> The normal practice is to mark the related Jira issue(s) with a 'breaking'
> label. We sometimes don't do that if the previous behavior was deemed a
> bug. In any case, I have marked both the relevant issues with the label
> now. I also updated the release notes to list those two issues under
> breaking changes; they should appear next time the website is re-built.
>
> Cheers, Paul.
>
>
> On Thu, Jun 8, 2017 at 10:43 PM, Winnebeck, Jason <
> jason.winneb...@windstream.com> wrote:
>
>> I see there is Elvis support for Optional, which is pretty cool.
>>
>> But when there are breaking changes like this that affect runtime
>> behavior without a change in code, is there a place where this is
>> documented when the release comes out? It would be a nice section to
>> include for Groovy 2.5 documentation a list of breaking changes so you can
>> find any issues in code.
>>
>> Jason
>>
>> -Original Message-
>> From: Jochen Theodorou [mailto:blackd...@gmx.org]
>> Sent: Tuesday, June 06, 2017 7:45 AM
>> To: d...@groovy.apache.org; users@groovy.apache.org
>> Subject: Groovy 2.5.0-beta-1 released
>>
>> Dear community,
>>
>> The Apache Groovy team is pleased to announce version 2.5.0-beta-1 of
>> Apache Groovy.
>> Apache Groovy is a multi-facet programming language for the JVM.
>> Further details can be found at the http://groovy.apache.org website.
>>
>> This is a pre-release of a new version of Groovy.
>> We greatly appreciate any feedback you can give us when using this
>> version.
>>
>> This release includes 8 bug fixes/improvements as outlined in the
>> changelog:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
>> ctId=12318123=12331949
>>
>> Sources can be downloaded from: http://www.groovy-lang.org/download.html
>> Convenience binaries, SDK and documentation can be found at:
>> http://www.groovy-lang.org/download.html
>> Jars are also available within the major binary repositories.
>> We would like to thank all people who contributed to this release.
>>
>> We welcome your help and feedback. For more information on how to report
>> problems, and to get involved, visit the project website at
>> https://groovy.apache.org/
>>
>> Best regards,
>>
>> The Apache Groovy team.
>>
>> This email message and any attachments are for the sole use of the
>> intended recipient(s). Any unauthorized review, use, disclosure or
>> distribution is prohibited. If you are not the intended recipient, please
>> contact the sender by reply email and destroy all copies of the original
>> message and any attachments.
>>
>
>

Re: Groovy 2.5.0-beta-1 released

[Paul King]

The normal practice is to mark the related Jira issue(s) with a 'breaking'
label. We sometimes don't do that if the previous behavior was deemed a
bug. In any case, I have marked both the relevant issues with the label
now. I also updated the release notes to list those two issues under
breaking changes; they should appear next time the website is re-built.

Cheers, Paul.


On Thu, Jun 8, 2017 at 10:43 PM, Winnebeck, Jason <
jason.winneb...@windstream.com> wrote:

> I see there is Elvis support for Optional, which is pretty cool.
>
> But when there are breaking changes like this that affect runtime behavior
> without a change in code, is there a place where this is documented when
> the release comes out? It would be a nice section to include for Groovy 2.5
> documentation a list of breaking changes so you can find any issues in code.
>
> Jason
>
> -Original Message-
> From: Jochen Theodorou [mailto:blackd...@gmx.org]
> Sent: Tuesday, June 06, 2017 7:45 AM
> To: d...@groovy.apache.org; users@groovy.apache.org
> Subject: Groovy 2.5.0-beta-1 released
>
> Dear community,
>
> The Apache Groovy team is pleased to announce version 2.5.0-beta-1 of
> Apache Groovy.
> Apache Groovy is a multi-facet programming language for the JVM.
> Further details can be found at the http://groovy.apache.org website.
>
> This is a pre-release of a new version of Groovy.
> We greatly appreciate any feedback you can give us when using this version.
>
> This release includes 8 bug fixes/improvements as outlined in the
> changelog:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12318123=12331949
>
> Sources can be downloaded from: http://www.groovy-lang.org/download.html
> Convenience binaries, SDK and documentation can be found at:
> http://www.groovy-lang.org/download.html
> Jars are also available within the major binary repositories.
> We would like to thank all people who contributed to this release.
>
> We welcome your help and feedback. For more information on how to report
> problems, and to get involved, visit the project website at
> https://groovy.apache.org/
>
> Best regards,
>
> The Apache Groovy team.
>
> This email message and any attachments are for the sole use of the
> intended recipient(s). Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply email and destroy all copies of the original
> message and any attachments.
>

Re: Java 8 Date/Time API Extension Methods

[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 +, 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.win...@ekiga.net
> > 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> > London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>

RE: Groovy 2.5.0-beta-1 released

[Winnebeck, Jason]

I see there is Elvis support for Optional, which is pretty cool.

But when there are breaking changes like this that affect runtime behavior 
without a change in code, is there a place where this is documented when the 
release comes out? It would be a nice section to include for Groovy 2.5 
documentation a list of breaking changes so you can find any issues in code.

Jason

-Original Message-
From: Jochen Theodorou [mailto:blackd...@gmx.org] 
Sent: Tuesday, June 06, 2017 7:45 AM
To: d...@groovy.apache.org; users@groovy.apache.org
Subject: Groovy 2.5.0-beta-1 released

Dear community,

The Apache Groovy team is pleased to announce version 2.5.0-beta-1 of Apache 
Groovy.
Apache Groovy is a multi-facet programming language for the JVM.
Further details can be found at the http://groovy.apache.org website.

This is a pre-release of a new version of Groovy.
We greatly appreciate any feedback you can give us when using this version.

This release includes 8 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12331949

Sources can be downloaded from: http://www.groovy-lang.org/download.html
Convenience binaries, SDK and documentation can be found at: 
http://www.groovy-lang.org/download.html
Jars are also available within the major binary repositories.
We would like to thank all people who contributed to this release.

We welcome your help and feedback. For more information on how to report 
problems, and to get involved, visit the project website at 
https://groovy.apache.org/

Best regards,

The Apache Groovy team.

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

Re: Java 8 Date/Time API Extension Methods

[Dinko Srkoč]

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 +, 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.win...@ekiga.net
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Re: Java 8 Date/Time API Extension Methods

[Daniel Sun]

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

[Russel Winder]

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 +, 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.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: Java 8 Date/Time API Extension Methods

[Dinko Srkoč]

On 8 June 2017 at 13:09, Russel Winder  wrote:
> On Wed, 2017-06-07 at 14:38 +, 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.win...@ekiga.net
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Re: Java 8 Date/Time API Extension Methods

[Russel Winder]

On Wed, 2017-06-07 at 14:38 +, 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.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part