Microsecond support in java.time.Duration/Instant? (original) (raw)
Kurt Alfred Kluever kak at google.com
Tue Jan 23 15:05:12 UTC 2018
- Previous message: Microsecond support in java.time.Duration/Instant?
- Next message: Microsecond support in java.time.Duration/Instant?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: Microsecond support in java.time.Duration/Instant?
- Next message: Microsecond support in java.time.Duration/Instant?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]