+1
Roger
On 12/22/2015 9:53 AM, Stephen Colebourne wrote:
Fine by me, thanks
Stephen
On 22 December 2015 at 07:59, nadeesh tv wrote:
Hi all,
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8143413/webrev.04/
Changes : Included the changes suggested by Stephen
Thanks and Re
Fine by me, thanks
Stephen
On 22 December 2015 at 07:59, nadeesh tv wrote:
> Hi all,
>
> Please see the updated webrev
> http://cr.openjdk.java.net/~ntv/8143413/webrev.04/
>
> Changes : Included the changes suggested by Stephen
>
> Thanks and Regards,
> Nadeesh
>
>
> On 12/22/2015 12:30 AM, Step
Hi all,
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8143413/webrev.04/
Changes : Included the changes suggested by Stephen
Thanks and Regards,
Nadeesh
On 12/22/2015 12:30 AM, Stephen Colebourne wrote:
The comment for the new LocalDate.EPOCH field should use 1970-01-01,
not
The comment for the new LocalDate.EPOCH field should use 1970-01-01,
not 1970-1-1. However, the code should omit the zeroes:
Replace:
LocalDate.of(1970, 01, 01)
with
LocalDate.of(1970, 1, 1)
The new method should follow the documentation of the similar method
on ChronoLocalDateTime:
* This
Hi all,
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8143413/webrev.03/
Thanks and Regards,
Nadeesh
On 12/4/2015 3:56 AM, Stephen Colebourne wrote:
In the interests of harmony and getting something in, I'll accept that.
I think LocalDate.EPOCH is probably better than LocalD
In the interests of harmony and getting something in, I'll accept that.
I think LocalDate.EPOCH is probably better than LocalDate.EPOCHDAY
Stephen
On 3 December 2015 at 22:09, Roger Riggs wrote:
> Hi Sherman,
>
> It makes sense to me to provide the missing time/date as an explicit
> parameter
Hi Sherman,
It makes sense to me to provide the missing time/date as an explicit
parameter
for toEpochSeconds instead of assuming some constant.
localDate.toEpochSeconds(LocalTime.MIDNIGHT, ZoneOffset.UTC);
localTime.toEpochSeconds(LocalDate.EPOCHDAY, ZoneOffset.UTC);
offsetTime.toEpochSeconds
On 12/1/15 6:36 AM, Stephen Colebourne wrote:
As Roger says, these new methods are about performance as well as conversion.
While I fully acknowledge the time methods make an assumption, it is
not a crazy one, after all 1970-01-01 is just zero.
Key I think is it allows:
long epochSecs = date.
As Roger says, these new methods are about performance as well as conversion.
While I fully acknowledge the time methods make an assumption, it is
not a crazy one, after all 1970-01-01 is just zero.
Key I think is it allows:
long epochSecs = date.toEpochSeconds(offset) + time.toEpochSeconds(offs
Hi Sherman,
On 11/30/2015 6:09 PM, Xueming Shen wrote:
On 11/30/2015 01:26 PM, Stephen Colebourne wrote:
Converting LocalDate<-> java.util.Date is the question with the
largest number of votes on SO:
http://stackoverflow.com/questions/21242110/convert-java-util-date-to-java-time-localdate/21242
On 11/30/2015 01:26 PM, Stephen Colebourne wrote:
Converting LocalDate<-> java.util.Date is the question with the
largest number of votes on SO:
http://stackoverflow.com/questions/21242110/convert-java-util-date-to-java-time-localdate/21242111
The proposed method is designed to make the conversi
Converting LocalDate <-> java.util.Date is the question with the
largest number of votes on SO:
http://stackoverflow.com/questions/21242110/convert-java-util-date-to-java-time-localdate/21242111
The proposed method is designed to make the conversion easier. It also
plugs an obvious gap in the API.
On 11/30/2015 10:37 AM, Stephen Colebourne wrote:
This is based on user difficulties picked up via Stack Overflow. These
methods aim to provide a simpler and faster approach, particularly for
cases converting to/from java.util.Date.
Can you be a little more specific on this one? We now have Inst
This is based on user difficulties picked up via Stack Overflow. These
methods aim to provide a simpler and faster approach, particularly for
cases converting to/from java.util.Date.
For the time cases, the convention of 1970-01-01 is natural and
commonly used in many codebases.
Stephen
On 30
Hi,
While it is kinda understandable to have LocalDate.toEpochSecond(...)
to get the epoch seconds since 1970.1.1, with the assumption of the
time is at the midnight of that day. It is strange to have the Local/OffsetTime
to have two public methods with the assumption of the "date" is at epoch
ye
The method Javadoc (specs) for each of the three new methods needs to
be enhanced.
For the date ones it needs to say
"The resulting date will have a time component of midnight at the
start of the day."
For the time ones it needs to say
"The resulting time will be on 1970-01-01."
Some of the line
16 matches
Mail list logo
