Milliseconds Resolution
Fairlight
fairlite at fairlite.com
Mon Sep 5 21:46:31 PDT 2016
On Tue, Sep 06, 2016 at 12:07:31AM -0400, Jose Lerebours via Filepro-list thus spoke:
> Yeah, if you want to do math as precise as that, you may want to
> look at using epoch time stamps. Like Mark said in his earlier
Epoch timestamps only have resolution to one second. That's what time(2)
uses. The high resolution time functions are gettimeofday/settimeofday,
which are used to manipulate the system clock. Those functions deal with a
structure which contains both the normal epoch time and the microseconds.
You can get the value with Perl (availeble by default since OSR5.6) with:
perl -e 'use Time::HiRes qw(gettimeofday); print(scalar(gettimeofday()),"\n");'
That said, what you'll get is a value like:
1473136389.76406
The part before the decimal is the epoch time, and the part after is the
microseconds.
There is no function or method provided for printing the time including
the microseconds in any standard format including the microseconds because
(TTBOMK) no such standard exists. Almost all system notations in *nix are
based only on epoch timestamps, while microseconds are mainly used for
sleep(), nap(), and alarm() (and their variants, by platform), as well as
getting/setting the system clock upon which they rely.
Feeding only the epoch time to localtime() yields exactly the same results
as feeding it the entire value returned. It's simply not built to handle
it. Nothing I see is, even in Time::HiRes.
You can use any of those external solutions to get the values, but BYOM.
(Bring Your Own Math.)
It might be useful to know why Stanley wants/needs the time to be that
fine-grained. Most tasks don't require that stringent a granularity.
Maybe there's an alternative, but we won't know that unless we hear the
task definition.
mark->
--
Audio panton, cogito singularis.
More information about the Filepro-list
mailing list