Re: Introduction of long term scheduling

From: M. Warner Losh <imp_at_BSDIMP.COM>
Date: Sat, 06 Jan 2007 09:35:59 -0700 (MST)

In message: <>
            Ashley Yakeley <ashley_at_SEMANTIC.ORG> writes:
: On Jan 5, 2007, at 20:14, Rob Seaman wrote:
: > An ISO string is really overkill, MJD can fit into
: > an unsigned short for the next few decades
: This isn't really a good idea. Most data formats have been moving
: away from the compact towards more verbose, from binary to text to
: XML. There are good reliability and extensibility reasons for this,
: such as avoiding bit-significance order issues and the ability to
: sanity-check it just by looking at it textually.

While all these date formats are mildly interesting, they are far too
inefficient for implementation by an OS.

OSes usually deal with timestamps all the time for various things. To
find out how much CPU to bill a process, to more mondane things.
Having to do all these gymnastics is going to hurt performance. One
might scoff at this statement, but research into performance problems
and issues has found time and again timekeeping and timestamps to have
a surprisingly large impact. So for the foreseeable future,
timestamps in OSes will be a count of seconds and a fractional second
part. That's not going to change anytime soon even with faster
machines, more memory, etc. Too many transaction processing
applications demand maximum speed.

: As the author of a library that consumes leap-second tables, my ideal
: format would look something like this: a text file with first line
: for MJD of expiration date, and each subsequent line with the MJD of
: the start of the offset period, a tab, and then the UTC-TAI seconds
: difference.

This sounds like a trivial variation on the NIST format for leapsecond

Received on Sat Jan 06 2007 - 09:23:48 PST

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