RFR:8143413:add toEpochSecond methods for efficient access
xueming.shen at oracle.com
Mon Nov 30 19:36:07 UTC 2015
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
> On 30 November 2015 at 18:15, Xueming Shen<xueming.shen at oracle.com> wrote:
>> 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
>> 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
>> 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
>>> Otherwise looks fine,
>>> 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;">
> <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"
> src="https://ipmcdn.avast.com/images/logo-avast-v1.png" style="width:
> 90px; height:33px;"/></a>
> <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
> target="_blank" style="color: #4453ea;">www.avast.com</a>
> </table><a href="#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
More information about the core-libs-dev