Microsecond support in java.time.Duration/Instant? (original) (raw)
Roger Riggs Roger.Riggs at Oracle.com
Tue Jan 23 14:54:13 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 ]
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 <mailto:scolebourne at joda.org>> wrote: On 22 January 2018 at 02:58, Kurt Alfred Kluever <kak at google.com_ _<mailto: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
- 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 ]