Bug 1412149

+++ This bug was initially created as a clone of Bug #1004416 +++

Description of problem:
Hi, then problem is based on
https://bugzilla.redhat.com/show_bug.cgi?id=960570
I've tried to use time to measure problem, but time itself is not able to deal with time shift and show incorrent result



How reproducible:
100%

Steps to Reproduce:
# CONST=70
# W=3
# time sleep $CONST& 
# BPID=$!
# sleep $W
# DOLD=`date`
# date -s "now - 1 minute"
# wait $BPID
# date -s "now + 1 minute"
# DNEW=`date`
# let DIFF=(`date +%s -d "$DNEW"` - `date +%s -d "$DOLD"`)
# echo $(($DIFF+$W)) == $CONST

Actual results:
time difference is 70 sec 
but time show:
real	0m10.001s
user	0m0.000s
sys	0m0.001s


Expected results:
real	1m10.001s

   Thanks&Regards
   Honza


--- Additional comment from Petr Pisar on 2013-09-09 12:24:20 GMT ---

Despite you use built-in `time', there is the same problem with GNU time.

I also think that time should measure monotonic (-alike) time not to get influenced by shifts in system clock.

clock_gettime(2) offers:

CLOCK_MONOTONIC -- suffers from NTP time adjustment.
CLOCK_MONOTONIC_RAW -- uses real hardware clock, I worry about precision and access permission for non-root users.
CLOCK_BOOTTIME -- includes time elapsed in suspension but suffers from NTP time adjustment. Is it worth?

I guess the CLOCK_MONOTONIC_RAW is the most appropriate.

--- Additional comment from Petr Pisar on 2014-10-21 13:15:50 GMT ---

Upstream agreed to use clock_gettime(CLOCK_MONOTONIC) for measuring the "real" value.

[...]

Patches posted to upstream <http://lists.gnu.org/archive/html/bug-gnu-utils/2016-12/msg00000.html>, but upstream seems dead.