Take the 2-minute tour ×

I see no such option for date

/proc/uptime is bootbased, not monotonic.

And at last I found cat /proc/timer_list | grep now which yields number of nsecs which is obtained via ktime_get which is returning monotonic time if I understand correctly, but that's quite cumbersome.

update: the returned value must be the same as returned by clock_gettime

share|improve this question
what precision do you need? –  Dru Sep 1 '13 at 4:54
So /proc/uptime is not monotonic? Is that a bug? –  auselen Sep 2 '13 at 8:05
@Dru at the moment I'm not concerned about precision. Something subsecond I'd expect. –  yaccz Sep 3 '13 at 12:54
I'm sorry, seriously can't understand why uptime is not monotonic. –  auselen Sep 3 '13 at 12:57
because it's bootbased –  yaccz Sep 3 '13 at 14:09
show 6 more comments

3 Answers

Looks like it's available in python 3.3: http://www.python.org/dev/peps/pep-0418/

Failing that, you could write a small C program which calls clock_gettime: http://linux.die.net/man/3/clock_gettime

share|improve this answer
That's what I don't want to. There must be a standard way to do this and if not, I'd rather patch coreutils. –  yaccz Aug 28 '13 at 16:58
Fair enough. I couldn't find anything usable from the shell except /proc/timer_list which you already found. –  jnylen Aug 28 '13 at 17:01
Please note that the man reference is not updated and now we have CLOCK_MONOTONIC_RAW that is not affected by changes made by ntp. –  olivecoder Sep 5 '13 at 12:12
add comment

In shell you could just use the date utility:

date +%s.%N
date +%s%N
nanoseconds_since_70=$(date +%s%N)

From man date:

       %N     nanoseconds (000000000..999999999)

The nanoseconds portion complement the seconds in the right way: when %N goes from 999999999 to 0 the %s increments one second. I dont have a reference for that (please edit if you can found it) but just works.

date utility x clock_gettime

Note that the number is not affected by changes in time zone but will be affected by changes in the system clock, like the changes made by the system administrator, NTP and adjtime function. However the CLOCK_MONOTONIC in the clock_gettime function is also affected, except by the administrator changes.

 CLOCK_MONOTONIC -- Clock  that  cannot  be set and represents monotonic time
 since some unspecified starting point.  This clock is not affected by 
 performed by adjtime(3) and NTP.

Newer system has a better solution: CLOCK_MONOTIC_RAW. Despite that, this is a shell solution as requested.

To know more

Monotonic function in Wikipedia

The @caf user answer from Difference between CLOCK_REALTIME and CLOCK_MONOTONIC?:

CLOCK_MONOTONIC represents the absolute elapsed wall-clock time since some
system time-of-day clock. 

machine without an intervening reboot, CLOCK_MONOTONIC is the best option.


That answer was posted before the question update adding the clock_gettime requirement. So I've earned two unfair downvotes after spend a lot of time writing and discussing to clarify.

share|improve this answer
Please could you, who downvoted, add a comment? Maybe I could fix my mistake and improve the stackoverflow for ourselves. –  olivecoder Sep 5 '13 at 11:30
This gives just the number of seconds since epoch. –  yaccz Sep 5 '13 at 11:34
To my knowledge this definition of monotonic is flawed in that it does not neccessarily is elapsed wall clocks. It doesn't even need to be in seconds. –  yaccz Sep 5 '13 at 11:35
the man clock_gettime does say "represents time since some unspecified starting point." but the starting point on linux is always the boot of the system (I'm not aware of any other possible starting point) –  yaccz Sep 5 '13 at 11:37
"This gives just the number of seconds since epoch.". Negative: this gives the number of nanoseconds since epoch. –  olivecoder Sep 5 '13 at 11:47
show 16 more comments

Consulting /proc/uptime is only cumbersome if you write out the full line each time. Why not wrap it up like this:

$ alias now="awk '/^now/ {print \$3; exit}' /proc/timer_list"
$ now

This also avoids the Useless Use of cat.

share|improve this answer
yep. That's the cumbersome. –  yaccz Sep 7 '13 at 15:50
Considering the syscall overhead, it's not that much worse than a binary calling clock_gettime(2). From a programming point of view, it's a single-word command to get the info wanted. I don't see the cumbersome, sorry. –  Phil Sep 7 '13 at 17:36
add comment

Your Answer


