Microsecond support in java.time.Duration/Instant?

[Alan Eliasen]

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.