RFR:8143413:add toEpochSecond methods for efficient access

[Xueming Shen]

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 Instance <=> Date,
and considerably we might add LocalDateTime <=> Date with an offset, if really
really desired (for performance? to save a Instant object as the bridge?).  But I'm
a little confused about the connection among LocalDate/LocalTime, epoch seconds
and j.u.Date here. Are you saying someone wants to convert

j.t.LocalDate -> epoch seconds -> j.u.Date
j.t.LocalTime -> epoch seconds -> j.u.Date

and uses the converted j.u.Date to represent a local date (date with time part to
be 0) and/or the local time (with year/month/day to be epoch time) in the "old"
system which only has j.u.Date, and has to use the j.u.Date to abstract the "local
date" and "local time"?

I think we agreed back to JSR310 that we don't try to add such kind of "bridge/
convenient/utility" methods into the new java.time package, but only in the
old date/calendar classes, if really needed. So if these methods are only to help
migrate/bridge between the "old" and "new" calendar systems, the java.time
might not be the best place for them?

> For the time cases, the convention of 1970-01-01 is natural and
> commonly used in many codebases.
>

I'm not sure about that, especially the "natural" part. It might be "common" in
the old days if you only have j.u.Date", and might be forced to use 1970-01-01
to fill in the "date" part even when you are really only interested in "time" part
of it in your app. One of the advantage of java.time.LDT/LD/LT is now we have
separate abstract for these different need, I don't see the common need of
having a LocalTime only meas the "local time" of 1970-01-01, or I misunderstood
something here.

-Sherman


> Stephen
>
>
>
> On 30 November 2015 at 18:15, Xueming Shen<xueming.shen at oracle.com>  wrote:
>> 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
>> year/month/day. What's the use case/scenario for these two proposed
>> methods?
>>
>> -Sherman
>>
>>
>> On 11/30/2015 06:36 AM, Stephen Colebourne wrote:
>>> 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 wrapping in the tests looks like it is not indented
>>> correctly.
>>>
>>> Otherwise looks fine,
>>> thanks
>>> Stephen
>>>
>>>
>>> On 30 November 2015 at 11:50, nadeesh tv<nadeesh.tv at oracle.com>   wrote:
>>>> 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/
>>>>
>>>> -- Thanks and Regards,
>>>> Nadeesh TV
>>
> <div id="DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><table
> style="border-top: 1px solid #aaabb6; margin-top: 10px;">
> 	<tr>
> 		<td style="width: 105px; padding-top: 15px;">
> 			<a href="https://www.avast.com/?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail"
> target="_blank"><img
> src="https://ipmcdn.avast.com/images/logo-avast-v1.png" style="width:
> 90px; height:33px;"/></a>
> 		</td>
> 		<td style="width: 470px; padding-top: 20px; color: #41424e;
> font-size: 13px; font-family: Arial, Helvetica, sans-serif;
> line-height: 18px;">This email has been sent from a virus-free
> computer protected by Avast.<br /><a
> href="https://www.avast.com/?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail"
> target="_blank" style="color: #4453ea;">www.avast.com</a>
> 		</td>
> 	</tr>
> </table><a href="#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
> height="1"></a></div>