Re: Design - a Tufte decision

From: M. Warner Losh <imp_at_BSDIMP.COM>
Date: Thu, 28 Dec 2006 10:00:18 -0700 (MST)

In message: <>
            Rob Seaman <> writes:
: On Dec 27, 2006, at 12:02 AM, M. Warner Losh wrote:
: > Calculating time intervals for times 6+ months in the future can be
: > the least of one's worries when one tries to code up a library to deal
: > gracefully with these different failure modes. The trivial case where
: > one has perfect knowledge of TAI-UTC and one can keep that knowledge
: > current is very simple in comparison. Dealing with this case is very
: > simple, and is the way most people think about leap seconds. But
: > dealing with the edge cases can be difficult because there are so
: > many, and so many that people forget to test or conceive of until the
: > call from the field comes in with a failure...
: A lot of these "edge" cases are really firmly centered in issues of
: real-time programming. Few versions of Unix are equipped to deal
: with real-time issues in even a rudimentary fashion. In any event,
: these cases have very little to do with leap seconds or any other
: aspects of the representation of time quantities.

Actually, they can have a great deal to do with it. The absolute need
to deal properly with these edge cases can, at times, lead to design
decisions that aren't the 'simplest'. I also disagree that Unix is
ill-equipted to deal with real-time issues. While one does need to
take care, I have successfully deployed over a dozen different types
of timing systems over the past 7 years on FreeBSD. My familiarity
with these edge cases, the customers that expect them to work and the
different sources of time has been learned through these experiences.
The nature of these customers also means that they are less well
connected to networks than one would like, which also complicates

The salient point from my ramblings is that different time scales may
become available at different points in time because data about them
is available at different points in time to the application/os. If
there's only one time scale, then once you know the time, you are
done. If there's more than one, then you need to either discover both
times, or you need to discover one time and the transforms to that
time to know the others.

Received on Thu Dec 28 2006 - 09:01:03 PST

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:55 PDT