Re: RFR:8143413:add toEpochSecond methods for efficient access

+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

Re: RFR:8143413:add toEpochSecond methods for efficient access

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,

Re: RFR:8143413:add toEpochSecond methods for efficient access

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

Re: RFR:8143413:add toEpochSecond methods for efficient access

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: *

Re: RFR:8143413:add toEpochSecond methods for efficient access

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

Re: RFR:8143413:add toEpochSecond methods for efficient access

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);

Re: RFR:8143413:add toEpochSecond methods for efficient access

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

Re: RFR:8143413:add toEpochSecond methods for efficient access

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 =

Re: RFR:8143413:add toEpochSecond methods for efficient access

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) +

Re: RFR:8143413:add toEpochSecond methods for efficient access

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:

Re: RFR:8143413:add toEpochSecond methods for efficient access

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.

Re: RFR:8143413:add toEpochSecond methods for efficient access

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

Re: RFR:8143413:add toEpochSecond methods for efficient access

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

Re: RFR:8143413:add toEpochSecond methods for efficient access

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

Re: RFR:8143413:add toEpochSecond methods for efficient access

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

RFR:8143413:add toEpochSecond methods for efficient access

Hi all, Please review a fix for Bug Id -https://bugs.openjdk.java.net/browse/JDK-8143413 Issue - add toEpochSecond methods for efficient access webrev - http://cr.openjdk.java.net/~ntv/8143413/webrev.01/