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.ri...@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 >> <scolebou...@joda.org <mailto:scolebou...@joda.org>> wrote: >> >> On 22 January 2018 at 02:58, Kurt Alfred Kluever <k...@google.com >> <mailto:k...@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.
