User: Password:
|
|
Subscribe / Log in / New account

How to ensure monotonic nondecreasing time

How to ensure monotonic nondecreasing time

Posted Nov 17, 2006 5:10 UTC (Fri) by zooko (guest, #2589)
In reply to: How to ensure monotonic nondecreasing time by pjm
Parent article: Counting on the time stamp counter

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".)


(Log in to post comments)

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?

See http://en.wikipedia.org/wiki/Coordinated_Universal_Time

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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds