Microsecond support in java.time.Duration/Instant? (original) (raw)

Alan Eliasen eliasen at mindspring.com
Tue Jan 23 22:43:28 UTC 2018

I'm not sure I want to bring this into the discussion, but there's a proposal (pushed largely by Facebook) for a timescale called the "flick" which is exactly 1/705600000 second.

Quote:

"This unit of time is the smallest time unit which is LARGER than a nanosecond, and can in integer quantities exactly represent a single frame duration for 24hz, 25hz, 30hz, 48hz, 50hz, 60hz, 90hz, 100hz, 120hz, and also 1/1000 divisions of each. This makes it suitable for use via std::chrono::duration and std::ratio for doing timing work against the system high resolution clock, which is in nanoseconds, but doesn't get slightly out of sync when doing common frame rates."

I can see useful properties of this when doing multimedia playback. They have C++ libraries implementing this unit. I'm not affiliated with this effort in any way, but saw it recently.

https://github.com/OculusVR/Flicks/blob/master/README.md

On January 23, 2018 7:54:13 AM MST, 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 <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

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

More information about the core-libs-dev mailing list