| |||||||||||||
|
| |||||||||||||
How to ensure monotonic nondecreasing timeHow to ensure monotonic nondecreasing timePosted Nov 16, 2006 6:26 UTC (Thu) by pjm (subscriber, #2080)Parent article: Counting on the time stamp counter One way of guaranteeing that ‘time never goes backwards’ is to use a variant of Lamport timestamps (or see full paper). For gettimeofday, we have it a bit easier: gettimeofday gives only microsecond precision, so it only guarantees that time never goes backwards, it doesn't guarantee that time advances between two events. Thus, we don't even need the property that distinct events have distinct timestamps, so we don't need the process ID stuff mentioned on that page, and we could go so far as to ~gratuitously drop the “and then applies rule 1 before timestamping the event as received” part from rule 3. [Dropping that part of rule 3 would more often expose callers mistakenly assuming that time strictly increases. Exposing bugs more often may be either a good or bad thing.]
(Log in to post comments)
How to ensure monotonic nondecreasing time Posted Nov 17, 2006 5:10 UTC (Fri) by zooko (subscriber, #2589) [Link] 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".)
How to ensure monotonic nondecreasing time Posted Nov 17, 2006 23:09 UTC (Fri) by giraffedata (subscriber, #1954) [Link] 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". Can you elaborate? I think you're saying that if I want a clock that correlates to UTC, it must necessarily step backwards sometimes. I don't see why.
How to ensure monotonic nondecreasing time Posted Nov 29, 2006 12:37 UTC (Wed) by robbe (subscriber, #16131) [Link] I guess zooko allured to leap seconds, where UTC stands still for(acually: jumps backwards by) a second. Maybe keeping TAI and the current delta is the answer to this one?
How to ensure monotonic nondecreasing time Posted Nov 29, 2006 17:19 UTC (Wed) by giraffedata (subscriber, #1954) [Link] I guess zooko alluded to leap seconds, where UTC stands still for (actually: jumps backwards by) a second. Ah. That's probably it. Except that UTC does not stand still or go backwards. When there's a leap second, UTC goes steadily forward from 23:59:59 to 23:59:60 and then to 00:00:00. Note that a UTC time of day is a tuple of numbers (year, month, day, hour, minute, second). But the standard Linux time representation (a single number) does step backward at leap second time; it's defined that way to make it easy to compute UTC from it. And I think zooko's statement that a programmer can't have a time that is both monotonically nondecreasing and correlates to a human time standard has to be qualified to the case that the time is represented by a single number. As long as you're willing to work with multiple numbers, two obvious ways are TAI + delta as you suggest, and just plain UTC.
|
|
||||||||||||