Programmers need to realize that they cannot have both monotonically non-decreasing (or monotonically increasing) *and* "correlates to shared human date-time e.g. UTC". Sometimes you require the latter and can live without the former. Sometimes it is the other way around.
Unfortunately Unix and Linux haven't traditionally offered the former to user-land programmers (although I'm told that Linux kernel code itself has long required monotonic timers for some things).
The current state of the art appears to be an ill-considered belief that you can have most of both most of the time (possibly because there is a human sysadmin finessing the difference for you) and and that the occasional violation of one or both of those requirements probably won't hurt too much. Bah. I hate that kind of irresponsible engineering.
("Occasional incorrectness won't hurt too much" thinking can often get by for years -- until a malicious actor gets involved who knows how to cause or to exploit this occasional incorrectness. In any case occasional incorrectness can occasionally cause planes to crash, precious documents to be deleted, etc.)
I believe that recent modern Linux and glibc do offer a monotonically increasing timer (i.e. implementing CLOCK_MONOTONIC for clock_gettime()). Now if only programmers will come to realize that they sometimes need it...
(P.S. An even more subtle and vexing problem is that you cannot have both monotonicity *and* "the rate of the passage of time correlates with a standard notion of the rate of time".)
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds