Microsecond support in java.time.Duration/Instant?

Kurt Alfred Kluever kak at google.com
Tue Jan 23 15:05:12 UTC 2018


Excellent, thanks Roger - I'll follow along there.

On Tue, Jan 23, 2018 at 9:54 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Hi Kurt,
>
> I created an enhancement request in the Jira and linked the core-libs
> emails in.
>     https://bugs.openjdk.java.net/browse/JDK-8196003
>
> Thanks for the frequency usage info.  Its hard to guess whether if micro
> APIs were
> available whether they would have been used instead of millis.
>
> Roger
>
>
>
> On 1/23/2018 12:23 AM, Kurt Alfred Kluever wrote:
>
> Thanks for the responses, Stephen + Roger,.
>
> As noted, a line definitely has to be drawn somewhere. In case anyone is
> looking for some data, here are current relative usage stats inside of
> Google for the various APIs, grouped by functionality (creating/decomposing
> Instants/Durations):
>
>   Instant.ofEpochMilli(long): 67%
>   Instant.ofEpochSecond(long): 29%
>
> *  Instants.ofEpochMicros(long): 4% *
>
>   Instant.toEpochMilli(): 83%
>   Instant.getEpochSecond(): 10%
> *  Instants.toEpochMicros(Instant): 7%*
>
>   Duration.ofSeconds(long): 30%
>   Duration.ofDays(long): 24%
>   Duration.ofMillis(long): 21%
>   Duration.ofMinutes(long): 18%
>   Duration.ofHours(long): 7%
>   Duration.ofNanos(long): < 1%
> *  Durations.ofMicros(long): < 1%*
>
>   Duration.toMillis(): 73%
>   Duration.getSeconds(): 16%
>   Duration.toMinutes(): 3%
>   Duration.toNanos(): 3%
>   Duration.toDays(): 3%
> *  Durations.toMicros(Duration): 2%*
>   Duration.toHours(): 1%
>
> So yea, it's definitely towards the bottom of the usage stats, but that
> also might be partially because of the discoverability issue (people are
> much more likely to find an instance method directly on the type than a
> static method on our Durations class). Anyway, I'm not claiming these
> numbers motivate any sort of change, but given a proposal to add
> microsecond support directly to the APIs, I think I'd be in favor :-) Or
> perhaps Google is unique in it's usage of microsecond precision (many of
> our storage systems have timestamps using microsecond precision).
>
> PS - and thanks for the ".NET ticks" reference, I hadn't heard of that
> before. And maybe here's a new one for you that just popped up in the news
> --- a Flick <https://github.com/OculusVR/Flicks> (1/705600000 of a
> second).
>
> On Mon, Jan 22, 2018 at 10:00 AM, Stephen Colebourne <scolebourne at joda.org
> > wrote:
>
>> On 22 January 2018 at 02:58, Kurt Alfred Kluever <kak at google.com> wrote:
>> > I'm curious how these sets of units were chosen or decided upon? I
>> > understand that the line must be drawn somewhere (or else someone may
>> come
>> > along asking for centisecond support), but I'm curious as to the
>> rational.
>>
>> Nanos have to be supported as they are the smallest available.
>> Millis are supported as they are the historic form.
>>
>> Micros is only one of the other possible ones - .NET ticks might be
>> another. A line has to be drawn somewhere...
>>
>> Stephen
>>
>
>
>
> --
> kak
>
>
>


-- 
kak


More information about the core-libs-dev mailing list