Microsecond support in java.time.Duration/Instant?
Kurt Alfred Kluever
kak at google.com
Tue Jan 23 05:23:09 UTC 2018
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.ofEpochMicros(long): 4%*
* Instants.toEpochMicros(Instant): 7%*
Duration.ofNanos(long): < 1%
* Durations.ofMicros(long): < 1%*
* Durations.toMicros(Duration): 2%*
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>
> 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
> > along asking for centisecond support), but I'm curious as to the
> 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...
More information about the core-libs-dev